2. David Evans http://www.cs.virginia.edu/~evans CS655: Programming Languages University of Virginia Computer Science Lecture 19: Minding Ps & Qs: Axiomatic Semantics and Program Verification It is easier to write an incorrect program than understand a correct one. Alan Perlis

3. 5 April 2001CS 655: Lecture 192 Operational Semantics Map to execution of a virtual machine Depends on informal understanding of machine Were able to prove that all programs in a language without loops terminate Awkward notion of equivalence Hard to prove properties about all possible executions of a program – need to simulate execution

4. 5 April 2001CS 655: Lecture 193 Static Semantics Can prove properties about simple properties (type checking) easily Cannot take into account any dynamic properties –Proofs must assume type of reference does not change throughout execution

5. 5 April 2001CS 655: Lecture 194 Axiomatic Semantics Reason about programs using axioms (mathematical rules about program text fragments) Depends on informal (almost formal) understanding of logic –Better than depending on informal understanding of Virtual Machine (Operational Semantics) Allows reasoning about all possible executions Can prove more interesting properties about programs than static semantics –Can deal with control flow, dynamic properties, etc.

6. 5 April 2001CS 655: Lecture 195 Floyd-Hoare Rules P { code fragment } Q Partial correctness: For all execution states which satisfy P, if the code fragment terminates, the resulting execution state satisfies Q. Total correctness: For all execution states which satisfy P, the code fragment terminates and the resulting execution state satisfies Q. (Sometimes people write: P [ code fragment ] Q.) pre-condition post-condition

7. 5 April 2001CS 655: Lecture 196 A simple example { true } while true do x := 1 { 2 + 2 = 5 } Partial correctness: Yes! Since code doesn’t terminate, any post-condition is satisfied. Total correctness: No!Since code doesn’t terminate, no total correctness post-condition could be satisfied.

8. 5 April 2001CS 655: Lecture 197 A Toy Language: Algorel Program ::= Statement Statement ::= Variable := Expression | Statement ; Statement | while Pred do Statement end Expression ::= Variable | IntLiteral | Expression + Expression | Expression * Expression Pred ::= true | false | Expression <= Expression

9. 5 April 2001CS 655: Lecture 198 Assignment Axiom P[e/x] { x := e  side-effect-free(e) } P P is true after x := e, iff P with e substituted for x was true before the assignment.

10. 5 April 2001CS 655: Lecture 199 Assignment Example wp { x := x + 1 } x = 3 P[e/x] { x := e  sef(e) } P wp = (x = 3)[x + 1/x] wp = ((x + 1)= 3) wp = (x = 2)

11. 5 April 2001CS 655: Lecture 1910 Weakest Preconditions P { S } Q Given Q and S, what is the weakest P such that P { S }  Q x = 2 { x := x + 1 } x = 3 Is there a stronger precondition? Is there a weaker precondition? Is there always a weakest precondition for any S and Q?

12. 5 April 2001CS 655: Lecture 1911 If Axiom side-effect-free (b)  (P  b { s1 } Q)  (P   b { s2 } Q) P { if b then s1 else s2 } Q

13. 5 April 2001CS 655: Lecture 1912 If Example P { if (x < 3) then x := x + 1 else x := x – 1 } x  3

14. 5 April 2001CS 655: Lecture 1913 If Example side-effect-free (x < 3)  (P  x < 3 { x := x + 1 } x  3 )  (P   (x < 3) { x := x – 1 } x  3 ) P { if (x < 3) then x := x + 1 else x := x – 1 } x  3 weakest-precondition: P = x  3  x  2

15. 5 April 2001CS 655: Lecture 1914 An Algorel Program Fragment % Pre-condition: ? while n <= x do n := n + 1; result := result * n; end % Post-condition: result = x!

16. 5 April 2001CS 655: Lecture 1915 Goal: find weakest pre-condition P & x 0 = x { while n <= x do n := n + 1; result := result * n; end } result = x 0 ! Elevator speech

17. 5 April 2001CS 655: Lecture 1916 Rule for while P  Inv  Inv { Pred }  Inv  Inv & Pred { Statement } Inv  (Inv & ~Pred)  Q  while Pred do Statement end terminates P { while Pred do Statement end } Q

18. 5 April 2001CS 655: Lecture 1917 What can go wrong? Invariant too weak –Can’t prove (Inv & ~Pred)  Q Invariant too strong –Can’t prove Inv & Pred { Statement } Inv –Can’t prove P  Inv (for sufficiently weak P)

19. 5 April 2001CS 655: Lecture 1918 Summary Once you have the right invariant, proving partial correctness is tedious but easy –Computers can do this quickly Picking the right invariant is hard and not well understood –Computers can do this slowly in special circumstances, often need help (from programmer or language designer) Next time: Proof-Carrying Code –Can quickly and automatically prove interesting properties (type safety, memory safety, etc.) about arbitrary code if you are given the right invariants