Lecture 19 Minding Ps Qs Axiomatic Semantics and

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 CS 655: Programming Languages David Evans University of Virginia 5 April 2001 CS 655: Lecture 19 http: //www. cs. virginia. edu/~evans Computer Science

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 5 April 2001 CS 655: Lecture 19 2

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 April 2001 CS 655: Lecture 19 3

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. 5 April 2001 CS 655: Lecture 19 4

Floyd-Hoare Rules pre-condition post-condition 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. ) 5 April 2001 CS 655: Lecture 19 5

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. 5 April 2001 CS 655: Lecture 19 6

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

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. 5 April 2001 CS 655: Lecture 19 8

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) 5 April 2001 CS 655: Lecture 19 9

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? 5 April 2001 CS 655: Lecture 19 10

If Axiom side-effect-free (b) (P b { s 1 } Q) (P b { s 2 } Q) P { if b then s 1 else s 2 } Q 5 April 2001 CS 655: Lecture 19 11

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

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 5 April 2001 CS 655: Lecture 19 13

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

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

Rule for while P Inv { Pred } Inv & Pred { Statement } Inv (Inv & ~Pred) Q while Pred do Statement end terminates P { while Pred do Statement end } Q 5 April 2001 CS 655: Lecture 19 16

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) 5 April 2001 CS 655: Lecture 19 17

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 5 April 2001 CS 655: Lecture 19 18