2. Simple Example {i = 0} j := i * i {j < 100} Can we ‘verify’ this triple? Only if we know the semantics of assignment.

3. The Assignment Rule {P} x := f {Q} where P and Q are the same, except that all the occurrences of x is P have been replaced by f. {i+1 > 0} i := i + 1 {i > 0}

4. Back To Our Simple Example {i = 0} j := i * i {j < 100} Ignore P for now and start with Q. Think backwards: “If j < 100 after j becomes i squared, then i squared must have been less than 100.” We have used the assignment rule backwards.

5. Back Substitution Back substitution is playing a “what if?” game by strict rules. Dijkstra’s “weakest precondition” method of correct program development is based on deriving the minimal precondition that must be satisfied such that the execution of the code results in the postcondition being true.

6. Back Substitution “At first glance, it may seem a bit odd to be working backward through the program. The advantage of working this way is that our reasoning is goal directed: At each step, knowing what we wish to be true at the conclusion of some part of the program, we compute what needs to be true prior to that part. When we reach the start of the program, we have the weakest pre- condition... We complete the proof by showing that the given pre-condition implies the weakest precondition” B. Liskov and J. Guttag. Abstraction and specification in program development. MIT Press, 1987.

7. Why Not Work Forward? By starting at the precondition and working forward we compute the strongest postcondition. To complete the proof we show that the strongest postcondition implies the desired postcondition. Problem: A lot of unneeded information might get carried along as the strongest postcondition is derived. How does symbolic execution address this issue?

8. Simple Assignment Example {i = 0} original P {i * i < 100} “weaker precondition” j := i * i {j < 100} original Q We need to show that {i = 0} implies {i * i < 100}

9. Stronger Preconditions Both {i = 0} and {i -10} are stronger assertions than {i * i < 100}

10. Another “Correct” Program {i = 0} j := i * i; i := -100 {j < 100} Be careful what you ask for in your postconditions!

11. A Stronger Postcondition {i = 0} j := i * i; i := -100 {j < 100 & i = i’} Use the “prime” notation to indicate the value of a variable in the previous state.

12. Discovering the Side Effect {i = 0} j := i * i; {j < 100 & -100 = i’} i := -100 {j < 100 & i = i’}

13. Discovering the Side Effect {i = 0} {i * i < 100 & -100 = i’} j := i * i; {j < 100 & -100 = i’} i := -100 {j < 100 & i = i’}

14. The Problem Revealed What do we do with {i = 0} implies {i * i < 100 & - 100 = i’}? drop the primes since there is no code left to consider attempt to prove that the antecedent implies the consequent