59
Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Embed Size (px)

Citation preview

Page 1: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Rigorous Software DevelopmentCSCI-GA 3033-011

Instructor: Thomas Wies

Spring 2012

Lecture 11

Page 2: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Semantics of Programming Languages

• Denotational Semantics– Meaning of a program is defined as the mathematical object it

computes (e.g., partial functions).– Example: Abstract Interpretation

• Axiomatic Semantics– Meaning of a program is defined in terms of its effect on the truth

of logical assertions.– Example: Hoare Logic

• (Structural) Operational Semantics– Meaning of a program is defined by formalizing the individual

computation steps of the program.– Example: Labeled Transition Systems

Page 3: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

IMP: A Simple Imperative Language

An IMP program:

p := 0;x := 0;while x < n do

x := x + 1;p := p + m;

Page 4: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Syntax of IMP Commands

• Commands (Com)c ::= skip

| x := e| c1 ; c2

| if b then c1 else c2

| while b do c• Notes:

– The typing rules have been embedded in the syntax definition.– Other parts are not context-free and need to be checked

separately (e.g., all variables are declared).– Commands contain all the side-effects in the language.– Missing: references, function calls, …

Page 5: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Labeled Transition Systems

A labeled transition system (LTS) is a structure LTS = (Q, Act, !) where– Q is a set of states,– Act is a set of actions,– ! µ Q £ Act £ Q is a transition relation.

We write q ! q’ for (q, a, q’) 2 !.a

Page 6: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

q q ++ {x n}x := e

Operational Semantics of IMP

<e, q> ⇓ nq qskip

q q’’c1 ; c2

q q’c1 q’ q’’c2

q q’if b then c1 else c2

<b, q> ⇓ true q q’c1

q q’if b then c1 else c2

<b, q> ⇓ false q q’c2

q q’’while b do c

<b, q> ⇓ true q q’c

q qwhile b do c

<b, q> ⇓ false

q’ q’’while b do c

Page 7: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Axiomatic Semantics

• An axiomatic semantics consists of:– a language for stating assertions about programs;– rules for establishing the truth of assertions.

• Some typical kinds of assertions:– This program terminates.– If this program terminates, the variables x and y have the same

value throughout the execution of the program.– The array accesses are within the array bounds.

• Some typical languages of assertions– First-order logic– Other logics (temporal, linear)– Special-purpose specification languages (Z, Larch, JML)

Page 8: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Assertions for IMP

• The assertions we make about IMP programs are of the form:

{A} c {B}with the meaning that:– If A holds in state q and q ! q’– then B holds in q’

• A is the pre-condition and B is the post-condition• For example:

{ y ≤ x } z := x; z := z + 1 { y < z }is a valid assertion

• These are called Hoare triples or Hoare assertions

c

Page 9: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Assertions for IMP

• {A} c {B} is a partial correctness assertion. It does not imply termination of c.

• [A] c [B] is a total correctness assertion meaning that– If A holds in state q– then there exists q’ such that q ! q

and B holds in state q’• Now let’s be more formal– Formalize the language of assertions, A and B– Say when an assertion holds in a state– Give rules for deriving Hoare triples

c

Page 10: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

The Assertion Language

• We use first-order predicate logic with IMP expressions

A :: = true | false | e1 = e2 | e1 ≥ e2

| A1 Æ A2 | A1 Ç A2 | A1 ) A2 | ∀x.A | ∃x.A

• Note that we are somewhat sloppy and mix the logical variables and the program variables.

• Implicitly, for us all IMP variables range over integers.• All IMP boolean expressions are also assertions.

Page 11: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Semantics of Assertions

• We introduced a language of assertions, we need to assign meanings to assertions.

• Notation q ² A to say that an assertion holds in a given state.– This is well-defined when q is defined on all variables

occurring in A.• The ² judgment is defined inductively on the

structure of assertions.• It relies on the semantics of arithmetic expressions

from IMP.

Page 12: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Semantics of Assertions

• q ² true always• q ² e1 = e2 iff <e1,q> ⇓ = <e2,q>⇓

• q ² e1 ≥ e2 iff <e1,q>⇓ ≥ <e2,q>⇓

• q ² A1 Æ A2 iff q ² A1 and q ² A2

• q ² A1 Ç A2 iff q ² A1 or q ² A2

• q ² A1 ) A2 iff q ² A1 implies q ² A2

• q ² ∀x.A iff 8n2Z. q[x:=n] ² A• q ² ∃x.A iff 9n2Z. q[x:=n] ² A

Page 13: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Semantics of Hoare Triples• Now we can define formally the meaning of a partial correctness

assertion:

² {A} c {B} iff

8q2Q. 8q’2Q. q ² A Æ q ! q’ ) q’ ² B• and the meaning of a total correctness assertion:

² [A] c [B] iff

8q2Q. q ² A ) 9q’∈Q. q ! q’ Æ q’ ² B

or even better:

8q2Q. 8q’∈Q. q ² A Æ q ! q’ ) q’ ² BÆ 8q2Q. q ² A ) 9q’2Q. q ! q’ Æ q’ ² B

c

c

c

c

Page 14: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Inferring Validity of Assertions

• Now we have the formal mechanism to decide when {A} c {B}– But it is not satisfactory,– because ² {A} c {B} is defined in terms of the operational

semantics.– We practically have to run the program to verify an assertion.– Also it is impossible to effectively verify the truth of a

∀x. A assertion (by using the definition of validity)• So we define a symbolic technique for deriving valid

assertions from others that are known to be valid– We start with validity of first-order formulas

Page 15: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

` A[e/x]

Inference Rules

• We write ` A when A can be inferred from basic axioms.• The inference rules for ` A are the usual ones from first-

order logic with arithmetic.• Natural deduction style axioms:

` A Æ B` A ` B

` A Ç B` A

` A Ç B` B

` 8 x. A` A[a/x] where

a is fresh` 8 x. A` A[e/x]

` 9 x. A ` B` 9 x. A ` B

` A ) B` B

` B` A ) B ` A

` A[a/x] ...

where a is fresh

` A ...

Page 16: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Inference Rules for Hoare Triples

• Similarly we write ` {A} c {B} when we can derive the triple using inference rules

• There is one inference rule for each command in the language.

• Plus, the rule of consequence

` A’ ) A ` {A} c {B} ` B ) B’ ` {A’} c {B’}

Page 17: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Inference Rules for Hoare Logic

• One rule for each syntactic construct:

` {A} skip {A} ` {A[e/x]} x:=e {A}

` {A} if b then c1 else c2 {B}` {A Æ b} c1 {B} ` {A Æ :b} c2 {B}

` {A} c1; c2 {C}` {A} c1 {B} ` {B} c2 {C}

` {I} while b do c {I Æ :b}` {I Æ b} c {I}

Page 18: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Hoare Rules

• For some construct, multiple rules are possible

alternative “forward axiom” for assignment:

alternative rule for while loops:

• These alternative rules are derivable from the previous rules, plus the rule of consequence.

` {A} x:=e {9x0. x0 = e Æ A[x0/x]}

` {I} while b do c {B}` {C} c {I} ` I Æ b ) C ` I Æ :b ) B

Page 19: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Exercise: Hoare Rules

• Is the following alternative rule for assignment still correct?

` {true} x:=e {x = e}

Page 20: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Example: Conditional

D1 :: ` {true Æ y ≤ 0} x := 1 {x > 0} D2 :: ` {true Æ y > 0} x := y {x > 0}

` {true} if y ≤ 0 then x := 1 else x := y {x > 0}

• D1 is obtained by consequence and assignment

` {1 > 0} x := 1 {x > 0}` true Æ y ≤ 0 ) 1 > 0` {true Æ y ≤ 0} x := 1 {x ≥ 0}

• D2 is also obtained by consequence and assignment

` {y > 0} x := y {x > 0}` true Æ y > 0 ) y > 0` {true Æ y > 0} x := y {x > 0}

Page 21: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Example: a simple loop

• We want to infer that` {x ≤ 0} while x ≤ 5 do x := x + 1 {x = 6}

• Use the rule for while with invariant I ´ x · 6

` x ≤ 6 Æ x ≤ 5 ) x + 1 ≤ 6 ` {x + 1 ≤ 6} x := x + 1 {x ≤ 6} ` {x ≤ 6 Æ x ≤ 5} x := x + 1 {x ≤ 6} ` {x ≤ 6} while x ≤ 5 do x := x + 1 { x ≤ 6 Æ x > 5}

• Then finish-off with the rule of consequence` x ≤ 0 ) x ≤ 6 ` x ≤ 6 Æ x > 5 ) x = 6 ` {x ≤ 6} while ... {x ≤ 6 Æ x > 5} ` {x ≤ 6} while ... { x ≤ 6 Æ x > 5}

Page 22: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Example: a more interesting program

• We want to derive that{n ¸ 0} p := 0; x := 0;while x < n do x := x + 1; p := p + m{p = n * m}

Page 23: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Example: a more interesting program

` {n ¸ 0} p:=0; x:=0; while x < n do (x:=x+1; p:=p+m) {p = n * m}

Only applicable rule (except for rule of consequence):

` {A} c1; c2 {B} ` {A} c1{C} ` {C} c2 {B}

c1 c2 BA

`{C} while x < n do (x:=x+1; p:=p+m) {p = n * m}` {n ¸ 0} p:=0; x:=0 {C}

Page 24: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Example: a more interesting program

` {n ¸ 0} p:=0; x:=0; while x < n do (x:=x+1; p:=p+m) {p = n * m}

What is C?

`{C} while x < n do (x:=x+1; p:=p+m) {p = n * m}` {n ¸ 0} p:=0; x:=0 {C}

Look at the next possible matching rules for c2!

Only applicable rule (except for rule of consequence):

` {I} while b do c {I Æ :b}` {I Æ b} c {I}

We can match {I} with {C} but we cannot match {I Æ :b} and {p = n * m} directly. Need to apply the rule of consequence first!

c1 c2 BA

Page 25: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Example: a more interesting program

` {n ¸ 0} p:=0; x:=0; while x < n do (x:=x+1; p:=p+m) {p = n * m}

What is C?

B’A’

`{C} while x < n do (x:=x+1; p:=p+m) {p = n * m}` {n ¸ 0} p:=0; x:=0 {C}

Look at the next possible matching rules for c2!

Only applicable rule (except for rule of consequence):

` {I} while b do c {I Æ :b}` {I Æ b} c {I}

` A’ ) A ` {A} c’ {B} ` B ) B’` {A’} c’ {B’}

Rule of consequence:

c’

c’A B

I = A = A’ = C

Page 26: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Example: a more interesting program

` {n ¸ 0} p:=0; x:=0; while x < n do (x:=x+1; p:=p+m) {p = n * m}

What is I?

`{I} while x < n do (x:=x+1; p:=p+m) {p = n * m}` {n ¸ 0} p:=0; x:=0 {I}

Let’s keep it as a placeholder for now!

` I Æ x ¸ n ) p = n * m`{I} while x < n do (x:=x+1; p:=p+m) {I Æ x ¸ n}

`{I Æ x<n} x := x+1; p:=p+m {I}

Next applicable rule:

` {A} c1; c2 {B} ` {A} c1{C} ` {C} c2 {B}

BA c1 c2

Page 27: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Example: a more interesting program

` {n ¸ 0} p:=0; x:=0; while x < n do (x:=x+1; p:=p+m) {p = n * m}

`{I} while x < n do (x:=x+1; p:=p+m) {p = n * m}` {n ¸ 0} p:=0; x:=0 {I} ` I Æ x ¸ n ) p = n * m

`{I} while x < n do (x:=x+1; p:=p+m) {I Æ x ¸ n}`{I Æ x<n} x := x+1; p:=p+m {I}

BA c1 c2

`{I Æ x<n} x := x+1 {C}

What is C? Look at the next possible matching rules for c2!Only applicable rule (except for rule of consequence):

` {A[e/x]} x:=e {A}

`{C} p:=p+m {I}

Page 28: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Example: a more interesting program

` {n ¸ 0} p:=0; x:=0; while x < n do (x:=x+1; p:=p+m) {p = n * m}

`{I} while x < n do (x:=x+1; p:=p+m) {p = n * m}` {n ¸ 0} p:=0; x:=0 {I} ` I Æ x ¸ n ) p = n * m

`{I} while x < n do (x:=x+1; p:=p+m) {I Æ x ¸ n}

What is C? Look at the next possible matching rules for c2!Only applicable rule (except for rule of consequence):

` {A[e/x]} x:=e {A}

`{I[p+m/p} p:=p+m {I}

`{I Æ x<n} x:=x+1; p:=p+m {I}

`{I Æ x<n} x:=x+1 {I[p+m/p]}

Page 29: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Example: a more interesting program

` {n ¸ 0} p:=0; x:=0; while x < n do (x:=x+1; p:=p+m) {p = n * m}

`{I} while x < n do (x:=x+1; p:=p+m) {p = n * m}` {n ¸ 0} p:=0; x:=0 {I} ` I Æ x ¸ n ) p = n * m

`{I} while x < n do (x:=x+1; p:=p+m) {I Æ x ¸ n}`{I Æ x<n} x:=x+1; p:=p+m {I}

`{I Æ x<n} x:=x+1 {I[p+m/p]}

Only applicable rule (except for rule of consequence):

` {A[e/x]} x:=e {A}

`{I[p+m/p} p:=p+m {I}

Need rule of consequence to match {I Æ x<n} and {I[x+1/x, p+m/p]}

Page 30: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Example: a more interesting program

` {n ¸ 0} p:=0; x:=0; while x < n do (x:=x+1; p:=p+m) {p = n * m}

`{I} while x < n do (x:=x+1; p:=p+m) {p = n * m}` {n ¸ 0} p:=0; x:=0 {I} ` I Æ x ¸ n ) p = n * m

`{I} while x < n do (x:=x+1; p:=p+m) {I Æ x ¸ n}`{I Æ x<n} x:=x+1; p:=p+m {I}

`{I Æ x<n} x:=x+1 {I[p+m/p]} ̀{I[p+m/p} p:=p+m {I}` I Æ x < n ) I[x+1/x, p+m/p]

`{I[x+1/x, p+m/p]} x:=x+1 {I[p+m/p]}

Let’s just remember the open proof obligations!

...

Page 31: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Example: a more interesting program

` {n ¸ 0} p:=0; x:=0; while x < n do (x:=x+1; p:=p+m) {p = n * m}

`{I} while x < n do (x:=x+1; p:=p+m) {p = n * m}` {n ¸ 0} p:=0; x:=0 {I}

` I Æ x ¸ n ) p = n * m

` I Æ x < n ) I[x+1/x, p+m/p]Let’s just remember the open proof obligations!

...Continue with the remaining part of the proof tree, as before.

` {I[0/x]} x:=0 {I}` {n ¸ 0} p:=0 {I[0/x]}

` {I[0/p, 0/x]} p:=0 {I[0/x]}` n ¸ 0 ) I[0/p, 0/x] Now we only need to solve the

remaining constraints!

Page 32: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Example: a more interesting program

` I Æ x ¸ n ) p = n * m

` I Æ x < n ) I[x+1/x, p+m/p]

Find I such that all constraints are simultaneously valid:

` n ¸ 0 ) I[0/p, 0/x]

I ´ p = x * m Æ x · n

` p = x * n Æ x · n Æ x ¸ n ) p = n * m

` p = p * m Æ x · n Æ x < n ) p+m = (x+1) * m Æ x+1 · n

` n ¸ 0 ) 0 = 0 * m Æ 0 · n

All constraints are valid!

Page 33: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Using Hoare Rules

• Hoare rules are mostly syntax directed• There are three obstacles to automation of Hoare logic

proofs:– When to apply the rule of consequence?– What invariant to use for while?– How do you prove the implications involved in the rule of

consequence?• The last one is how theorem proving gets in the picture

– This turns out to be doable!– The loop invariants turn out to be the hardest problem!– Should the programmer give them?

Page 34: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Hoare Logic: Summary

• We have a language for asserting properties of programs.• We know when such an assertion is true.• We also have a symbolic method for deriving assertions.

A{A} P {B}

² A² {A} P {B}

` A` {A} P {B}

semantics

soundness

completenesstheorem proving

Page 35: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Verification Conditions

• Goal: given a Hoare triple {A} P {B}, derive a single assertion VC(A,P,B) such that ² VC(A,P,B) iff ² {A} P {B}

• VC(A,P,B) is called verification condition.• Verification condition generation factors out the hard work

– Finding loop invariants– Finding function specifications

• Assume programs are annotated with such specifications– We will assume that the new form of the while construct includes

an invariant:{I} while b do c

– The invariant formula I must hold every time before b is evaluated.

Page 36: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Verification Condition Generation

• Idea for VC generation: propagate the post-condition backwards through the program:– From {A} P {B} – generate A ) F(P, B)

• This backwards propagation F(P, B) can be formalized in terms of weakest preconditions.

Page 37: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Weakest Preconditions

• The weakest precondition WP(c,B) holds for any state q whose c-successor states all satisfy B:

q ² WP(c,B) iff 8q’2Q. q ! q’ ) q’ ² B

• Compute WP(P,B) recursively according to the structure of the program P.

BWP(c,B)q q’ q’’

cc

c

c

Page 38: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Loop-Free Guarded Commands

• Introduce loop-free guarded commands as an intermediate representation of the verification condition

• c ::= assume b| assert b| havoc x| c1 ; c2

| c1 c2

Page 39: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Operational Semantics of GCs

• States of guarded commands are variable assignments plus flow component:

Q = (L ! Z) £ FlowFlow ::= Norm | Error

• Extend satisfiability of assertions to GC states:

(s, flow) ² A iff flow = Norm Æ s ² A

Page 40: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

(s, Norm) (s[x := n], Norm)havoc x

Operational Semantics of GCs

n 2 Z

(s, Norm) (s, Norm)assume b

s ² b

(s, Norm) (s, Norm)assert b

s ² b

(s, Norm) (s, Error)assert b

s ² :b

Page 41: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Operational Semantics of GCs

(s, Norm) q’’c1 ; c2

(s, Norm) q’c1 q’ q’’c2

(s, Norm) q’c1 c2

(s, Norm) q’c1

(s, Error) (s, Error)c

(s, Norm) q’c1 c2

(s, Norm) q’c2

Page 42: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

From Programs to Guarded Commands

• GC(skip) = assume true

• GC(x := e) = assume tmp = x; havoc x; assume (x =

e[tmp/x])• GC(c1 ; c2) =

GC(c1) ; GC(c2)

• GC(if b then c1 else c2) =(assume b; GC(c1)) (assume :b; GC(c2))

• GC({I} while b do c) = ?

where tmp is fresh

Page 43: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Guarded Commands for Loops

• GC({I} while b do c) =assert I;havoc x1; ...; havoc xn;assume I;(assume b; GC(c); assert I; assume false)

assume :b

where x1, ..., xn are the variables modified in c

Page 44: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Computing Weakest Preconditions

• WP(assume b, B) = b ) B• WP(assert b, B) = b Æ B• WP(havoc x, B) = B[a/x] (a fresh in B)• WP(c1;c2, B) = WP(c1, WP(c2, B))

• WP(c1 c2,B) = WP(c1, B) Æ WP(c2, B)

Page 45: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Putting Everything Together

• Given a Hoare triple H ´ {A} P {B}

• Compute cH = assume A; GC(P); assert B

• Compute VCH = WP(cH, true)

• Infer ` VCH using a theorem prover.

Page 46: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Example: VC Generation

{n ¸ 0} p := 0; x := 0; {p = x * m Æ x · n}while x < n do x := x + 1; p := p + m{p = n * m}

Page 47: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

assume n ¸ 0;GC( p := 0;

x := 1; {p = x * m Æ x · n}while x < n do

x := x + 1; p := p + m );assert p = n * m

assume n ¸ 0;assume p0 = p; havoc p; assume p = 0;

GC( x := 0; {p = x * m Æ x · n}while x < n do

x := x + 1; p := p + m );assert p = n * m

assume n ¸ 0;assume p0 = p; havoc p; assume p = 0;

assume x0 = x; havoc x; assume x = 0;

GC( {p = x * m Æ x · n}while x < n do

x := x + 1; p := p + m );assert p = n * m

assume n ¸ 0;assume p0 = p; havoc p; assume p = 0;

assume x0 = x; havoc x; assume x = 0;

assert p = x * m Æ x · n;havoc x; havoc p; assume p = x * m Æ x · n; (assume x < n; GC( x := x + 1; p := p + m); assert p = x * m Æ x · n; assume false) assume x ¸ n;assert p = n * m

assume n ¸ 0;assume p0 = p; havoc p; assume p = 0;

assume x0 = x; havoc x; assume x = 0;

assert p = x * m Æ x · n;havoc x; havoc p; assume p = x * m Æ x · n; (assume x < n; assume x1 = x; havoc x; assume x = x1 + 1; assume p1 = p; havoc p; assume p = p1 + m; assert p = x * m Æ x · n; assume false) assume x ¸ n;assert p = n * m

• Computing the guarded command

Example: VC Generation

Page 48: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

WP ( assume n ¸ 0;assume p0 = p; havoc p; assume p = 0;

assume x0 = x; havoc x; assume x = 0;

assert p = x * m Æ x · n;havoc x; havoc p; assume p = x * m Æ x · n;

(assume x < n; assume x1 = x; havoc x; assume x = x1 + 1; assume p1 = p; havoc p; assume p = p1 + m; assert p = x * m Æ x · n; assert false)

assume x ¸ n;assert p = n * m, true)

WP ( assume n ¸ 0;assume p0 = p; havoc p; assume p = 0;

assume x0 = x; havoc x; assume x = 0;

assert p = x * m Æ x · n;havoc x; havoc p; assume p = x * m Æ x · n;

(assume x < n; assume x1 = x; havoc x; assume x = x1 + 1; assume p1 = p; havoc p; assume p = p1 + m; assert p = x * m Æ x · n; assert false)

assume x ¸ n, assert p = n * m, true)

WP ( assume n ¸ 0;assume p0 = p; havoc p; assume p = 0;

assume x0 = x; havoc x; assume x = 0;

assert p = x * m Æ x · n, WP( havoc x; havoc p; assume p = x * m Æ x · n; (assume x < n; assume x1 = x; havoc x; assume x = x1 + 1; assume p1 = p; havoc p; assume p = p1 + m; assert p = x * m Æ x · n; assume false)

assume x ¸ n, p = n * m)

WP ( assume n ¸ 0;assume p0 = p; havoc p; assume p = 0;

assume x0 = x; havoc x; assume x = 0;

assert p = x * m Æ x · n, WP( havoc x; havoc p; assume p = x * m Æ x · n; (assume x < n; assume x1 = x; havoc x; assume x = x1 + 1; assume p1 = p; havoc p; assume p = p1 + m; assert p = x * m Æ x · n; assume false)

assume x ¸ n, p = n * m)

• Computing the weakest preconditionWP ( assume n ¸ 0;

assume p0 = p; havoc p; assume p = 0;

assume x0 = x; havoc x; assume x = 0;

assert p = x * m Æ x · n, WP( havoc x; havoc p; assume p = x * m Æ x · n; (WP( (assume x < n; assume x1 = x; havoc x; assume x = x1 + 1; assume p1 = p; havoc p; assume p = p1 + m; assert p = x * m Æ x · n; assume false)) )

p = n * m) Æ (x ¸ n ) p = n * m)

WP ( assume n ¸ 0;assume p0 = p; havoc p; assume p = 0;

assume x0 = x; havoc x; assume x = 0;

assert p = x * m Æ x · n, WP( havoc x; havoc p; assume p = x * m Æ x · n; (WP( (assume x < n; assume x1 = x; havoc x; assume x = x1 + 1; assume p1 = p; havoc p; assume p = p1 + m; assert p = x * m Æ x · n), false ) p = n * m) Æ (x ¸ n ) p = n * m)

WP ( assume n ¸ 0;assume p0 = p; havoc p; assume p = 0;

assume x0 = x; havoc x; assume x = 0;

assert p = x * m Æ x · n, WP( havoc x; havoc p; assume p = x * m Æ x · n; (WP( (assume x < n; assume x1 = x; havoc x; assume x = x1 + 1; assume p1 = p; havoc p; assume p = p1 + m; assert p = x * m Æ x · n), true) Æ (x ¸ n ) p = n * m)

WP ( assume n ¸ 0;assume p0 = p; havoc p; assume p = 0;

assume x0 = x; havoc x; assume x = 0;

assert p = x * m Æ x · n, WP( havoc x; havoc p; assume p = x * m Æ x · n; (WP( (assume x < n; assume x1 = x; havoc x; assume x = x1 + 1; assume p1 = p; havoc p;

p = p1 + m ) p = x * m Æ x · n)

Æ (x ¸ n ) p = n * m)

WP ( assume n ¸ 0;assume p0 = p; havoc p; assume p = 0;

assume x0 = x; havoc x; assume x = 0;

assert p = x * m Æ x · n, WP(havoc x; havoc p; assume p = x * m Æ x · n; (WP( (assume x < n; assume x1 = x; havoc x; assume x = x1 + 1), p1 = p Æ pa1 = p1 + m ) pa1 = x * m Æ x · n)

Æ (x ¸ n ) p = n * m)

WP ( assume n ¸ 0;assume p0 = p; havoc p; assume p = 0;

assume x0 = x; havoc x; assume x = 0;

assert p = x * m Æ x · n, WP(havoc x; havoc p; assume p = x * m Æ x · n; (WP( assume x < n ), x1 = x Æ xa1 = x1 + 1 Æ p1 = p Æ pa1 = p1 + m ) pa1 = xa1 * m Æ xa1 · n)

Æ (x ¸ n ) p = n * m)

WP ( assume n ¸ 0;assume p0 = p; havoc p; assume p = 0;

assume x0 = x; havoc x; assume x = 0;

assert p = x * m Æ x · n, WP(havoc x; havoc p; assume p = x * m Æ x · n; ((x < n Æ x1 = x Æ xa1 = x1 + 1 Æ p1 = p Æ pa1 = p1 + m) ) pa1 = xa1 * m Æ xa1 · n)

Æ (x ¸ n ) p = n * m)

WP ( assume n ¸ 0;assume p0 = p; havoc p; assume p = 0;

assume x0 = x; havoc x; assume x = 0;

assert p = x * m Æ x · n, pa2 = xa2 * m Æ xa2 · n )

((xa2 < n Æ x1 = xa2 Æ xa1 = x1 + 1 Æ p1 = pa2 Æ pa1 = p1 + m) ) pa1 = xa1 * m Æ xa1 · n)

Æ (xa2 ¸ n ) pa2 = n * m)

n ¸ 0 Æ p0 = p Æ pa3 = 0 Æ x0 = x Æ xa3 = 0 )

pa3 = xa3 * m Æ xa3 · n Æ

(pa2 = xa2 * m Æ xa2 · n )

((xa2 < n Æ x1 = xa2 Æ xa1 = x1 + 1 Æ p1 = pa2 Æ pa1 = p1 + m) ) pa1 = xa1 * m Æ xa1 · n)

Æ (xa2 ¸ n ) pa2 = n * m))

Example: VC Generation

Page 49: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

• The resulting VC is equivalent to the conjunction of the following implications

Example: VC Generation

n ¸ 0 Æ p0 = p Æ pa3 = 0 Æ x0 = x Æ xa3 = 0 ) pa3 = xa3 * m Æ xa3 · n

n ¸ 0 Æ p0 = p Æ pa3 = 0 Æ x0 = x Æ xa3 = 0 Æ pa2 = xa2 * m Æ xa2 · n )

xa2 ¸ n ) pa2 = n * m

n ¸ 0 Æ p0 = p Æ pa3 = 0 Æ x0 = x Æ xa3 = 0 Æ pa2 = xa2 * m Æ xa2 < n Æ x1 = xa2 Æ xa1 = x1 + 1 Æ p1 = pa2 Æ pa1 = p1 + m )

pa1 = xa1 * m Æ xa1 · n

Page 50: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

• simplifying the constraints yields

• all of these implications are valid, which proves that the original Hoare triple was valid, too.

Example: VC Generation

n ¸ 0 ) 0 = 0 * m Æ 0 · n

xa2 · n Æ xa2 ¸ n ) xa2 * m = n * m

xa2 < n ) xa2 * m + m = (xa2 + 1) * m Æ xa2 + 1 · n

Page 51: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

The Diamond Problem

assume A; c d;c’ d’;assert B

A ) WP (c, WP(c’, B) Æ WP(d’, B)) Æ WP (d, WP(c’, B) Æ WP(d’, B))

• Number of paths through the program can be exponential in the size of the program.

• Size of weakest precondition can be exponential in the size of the program.

c

c’

d

d’

Page 52: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Avoiding the Exponential ExplosionDefer the work of exploring all paths to the theorem prover:

• WP’(assume b, B, C) = (b ) B, C)• WP’(assert b, B, C) = (b Æ B, C)• WP’(havoc x, B, C) = (B[a/x], C) (a fresh in B)• WP’(c1;c2, B, C) =

let F2, C2 = WP’(c2, B, C) in WP’(c1, F2, C2)

• WP’(c1 c2,B, C) =let X = fresh propositional variable inlet F1, C1 = WP’(c1, X, true) and F2, C2 = WP’(c2, X, true) in(F1 Æ F2, C Æ C1 Æ C2 Æ (X , B))

• WP(P, B) = let F, C = WP’(P, B, true) in C ) F

Page 53: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Translating Method Calls to GCs

/*@ requires P; @ assignable x1, ..., xn;

@ ensures Q; T m (T1 p1, ..., Tk pk) { ... }

A method call y = x.m(y1, ..., yk);

is desugared into the guarded command assert P[x/this, y1/p1, ..., yk/pk];

havoc x1; ..., havoc xn; havoc y;

assume Q[x/this, y/\result]

Page 54: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Handling More Complex Program State

• When is the following Hoare triple valid?{A} x.f = 5 {x.f + y.f = 10}

• A ought to imply “y.f = 5 Ç x = y”• The IMP Hoare rule for assignment would give us:

(x.f + y.f = 10) [5/x.f]´ 5 + y.f = 10´ y.f = 5 (we lost one case)

• How come the rule does not work?

Page 55: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Modeling the Heap

• We cannot have side-effects in assertions– While generating the VC we must remove side-effects!– But how to do that when lacking precise aliasing information?

• Important technique: postpone alias analysis to the theorem prover

• Model the state of the heap as a symbolic mapping from addresses to values:– If e denotes an address and h a heap state then:– sel(h,e) denotes the contents of the memory cell– upd(h,e,v) denotes a new heap state obtained from h by

writing v at address e

Page 56: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Heap Models

• We allow variables to range over heap states– So we can quantify over all possible heap states.

• Model 1– One “heap” for each object– One index constant for each field.

We postulate f1 ≠ f2.– r.f1 is sel(r,f1) and r.f1 = e is r := upd(r,f1,e)

• Model 2 (Burnstall-Bornat)– One “heap” for each field– The object address is the index– r.f1 is sel(f1,r) and r.f1 = e is f1 := upd(f1,r,e)

Page 57: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Hoare Rule for Field Writes

• To model writes correctly, we use heap expressions– A field write changes the heap of that field

{ B[upd(f, e1, e2)/f] } e1.f = e2 {B}

• Important technique: model heap as a semantic object• And defer reasoning about heap expressions to the

theorem prover with inference rules such as (McCarthy):

sel(upd(h, e1, e2), e3) =

e2 if e1 = e3

sel(h, e3) if e1 ≠ e3

Page 58: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Example: Hoare Rule for Field Writes

• Consider again: { A } x.f = 5 { x.f + y.f = 10 }• We obtain:

A ´ (x.f + y.f = 10)[upd(f, x, 5)/f] ´ (sel(f, x) + sel(f, y) = 10)[upd(f, x, 5)/f]´ sel(upd(f x 5) x) + sel(upd(f x 5) y) = 10 (*)´ 5 + sel(upd(f, x, 5), y) = 10´ if x = y then 5 + 5 = 10 else 5 + sel(f, y) = 10´ x = y Ç y.f = 5 (**)

• To (*) is theorem generation.• From (*) to (**) is theorem proving.

Page 59: Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 11

Modeling new Statements• Introduce

– a new predicate isAllocated(e, t) denoting that object e is allocated at allocation time t

– and a new variable allocTime denoting the current allocation time.

• Add background axioms:allocTime = 08x t. isAllocated(x, t) ) isAllocated(x, t+1)isAllocated(null, 0)

• Translate new x.T() tohavoc x;assume :isAllocated(x, allocTime);assume Type(x) = T;assume isAllocated(x, allocTime + 1);allocTime := allocTime + 1;**Translation of call to constructor x.T()**