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
CS655: Programming Languages
David Evans
University of Virginia
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
Statement ::=
Variable := Expression
| Statement ; Statement
| while Pred do Statement end
Expression ::= Variable | IntLiteral
| 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 { s1 } Q)
(P b { s2 } Q)
P { if b then s1 else s2 } Q
5 April 2001
CS 655: Lecture 19
11
If Example
P
{ if (x < 3) then x := x + 1 else x := x – 1 }
x3
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 & x0 = x
{
while n <= x do
n := n + 1;
result := result * n;
end
}
result = x0!
5 April 2001
CS 655: Lecture 19
Elevator speech
15
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
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
© Copyright 2026 Paperzz