• Still need volunteers to teach – BDDs – SAT-solvers Axiomatic Semantics – SAT-based decision procedures – Temporal logic (and maybe other modal logics) – ESC/Java • Please let me know soon Automated Deduction - George Necula - Lecture 2 1 Automated Deduction - George Necula - Lecture 2 2 Review - Operational Semantics More Semantics • We have an imperative language with pointers and • There is also denotational semantics function calls – Each program has a meaning in the form of a mathematical object – Compositional • We have defined the semantics of the language – More complex formalism • e.g. what are appropriate meanings ? • Operational semantics – Relatively simple • Neither is good for arguing program correctness – Not compositional (due to loops and recursive calls) – Operational semantics requires running the code – Adequate guide for an implementation – Denotational semantics requires complex calculations • We do instead: Programs → Theorems → Proofs Automated Deduction - George Necula - Lecture 2 3 Automated Deduction - George Necula - Lecture 2 4 Programs →→→ Theorems. Axiomatic Semantics Partial Correctness Assertions • Consists of: • The assertions we make about programs are of the – A language for making assertions about programs form: – Rules for establishing when assertions hold {A} c {B } with the meaning that: • Typical assertions: – Whenever we start the execution of c in a state that – During the execution, only non-null pointers are dereferenced satisfies A, the program either does not terminate or it – This program terminates with x = 0 terminates in a state that satisfies B • A is called precondition and B is called postcondition • Partial vs. total correctness assertions • For example: – Safety vs. liveness properties { y x } z := x; z := z +1 { y < z } – Usually focus on safety (partial correctness) is a valid assertion • These are called Hoare triple or Hoare assertions Automated Deduction - George Necula - Lecture 2 5 Automated Deduction - George Necula - Lecture 2 6 1 Total Correctness Assertions Languages for Assertions • {A} c {B } is a partial correctness assertion. It does • A specification language not imply termination – Must be easy to use and expressive (conflicting needs) • [A] c [B ] is a total correctness assertion meaning that • Most often only expression – Syntax: how to construct assertions Whenever we start the execution of c in a state that satisfies A the program does terminate in a state that – Semantics: what assertions mean satisfies B • Typical examples • Now let’s be more formal – First-order logic – Formalize the language of assertions, A and B – Temporal logic (used in protocol specification, hardware – Say when an assertion holds in a state specification) – Give rules for deriving Hoare triples – Special-purpose languages: Z, Larch, Java ML Automated Deduction - George Necula - Lecture 2 7 Automated Deduction - George Necula - Lecture 2 8 State-Based Assertions An Assertion Language • Assertions that characterize the state of the • We’ll use a fragment of first-order logic first ⊥⊥⊥ ∧ ∀ execution Formulas P ::= A | T | | P 1 P2 | x.P | P 1 ⇒ P2 | ≤ – Recall: state = state of locals + state of memory Atoms A ::= f(A 1,…,A n) | E 1 E2 | E 1 = E 2 | … • Our assertions will need to be able to refer to • We can also have an arbitrary assortment of function – Variables symbols – Contents of memory – ptr(E,T) - expression E denotes a pointer to T – E : ptr(T) - same in a different notation • What are not state-based assertions – reachable(E 1,E 2) - list cell E 2 is reachable from E 1 – Variable x is live, lock L will be released – these can be built-in or defined – There is no correlation between the values of x and y Automated Deduction - George Necula - Lecture 2 9 Automated Deduction - George Necula - Lecture 2 10 Semantics of Assertions Semantics of Assertions • We introduced a language of assertions, we need to • Formal definition (we drop σ for simplicity): assign meanings to assertions. – We ignore for now references to memory ρ true always ρ ρ ρ e1 = e 2 iff ⊢ e1 ⇓ n1 and ⊢ e2 ⇓ n2 and n 1 = n 2 • Notation ρ, σ A to say that an assertion holds in a ρ e ≥ e iff ρ ⊢ e ⇓ n and ρ ⊢ e ⇓ n and n ≥ n given state. 1 2 1 1 2 2 1 2 ρ ∧ ρ ρ – This is well-defined when ρ is defined on all variables A1 A2 iff A1 and A2 σ ρ ρ ρ occurring in A and is defined on all memory addresses A1 ∨ A2 iff A1 or A2 referenced in A ρ ρ ρ A1 ⇒ A2 iff A1 implies A2 ρ ∀x.A iff ∀n∈Z.ρ[x:=n] A • The judgment is defined inductively on the ρ ∃ ∃ ∈Z ρ structure of assertions. x.A iff n . [x:=n] A Automated Deduction - George Necula - Lecture 2 11 Automated Deduction - George Necula - Lecture 2 12 2 Semantics of Assertions Why Isn’t This Enough? • Now we can define formally the meaning of a partial • Now we have the formal mechanism to decide when correctness assertion {A} c {B } { A} c { B }: – Start the program in all states that satisfies A ∀ρσ .∀ρ’σ’.( ρ,σ A ∧ ρ, σ ⊢ c ⇓ ρ’, σ’) ⇒ ρ’,σ’ B – Run the program – Check that each final state satisfies B • … and the meaning of a total correctness assertion • This is exhaustive testing [A] c [B] iff • Not enough ∀ ρσ.∀ρ’σ’.( ρ,σ A ∧ ρ, σ ⊢ c ⇓ ρ’, σ’) ⇒ ρ’,σ’ B – Can’t try the program in all states satisfying the precondition ∧ – Can’t find all final states for non-deterministic programs ∀ρσ. ρ,σ A ⇒ ∃ρ’σ’. ρ, σ ⊢ c ⇓ ρ’, σ’ – And also it is impossible to effectively verify the truth of a ∀x.A postcondition (by using the definition of validity) Automated Deduction - George Necula - Lecture 2 13 Automated Deduction - George Necula - Lecture 2 14 Derivations as Proxies for Validity Derivation Rules for Assertions • We define a symbolic technique for deriving valid • The derivation rules for ⊢ A are the usual ones from assertions from others that are known to be valid first-order logic with – We start with validity of first-order formulas • Natural deduction style axioms: ⊢ • We write A when we can derive (prove) the ⊢ A ⊢ B ⊢ [a/x]A (a is fresh) ⊢ ∀x.A assertion A ⊢ A ∧ B ⊢ ∀x.A ⊢ [E/x]A – We wish that (∀ρσ . ρ,σ A) iff ⊢ A ⊢ [a/x]A ⊢ ⊢ A • We write {A} c {B} when we can derive (prove) the … … partial correctness assertion ⊢ ∃ ⊢ ⊢ B ⊢ A ⇒ B ⊢ A ⊢ [E/x]A x.A B – We wish that {A} c {B} iff ⊢ {A} c {B} ⊢ A ⇒ B ⊢ B ⊢ ∃x.A ⊢ B Automated Deduction - George Necula - Lecture 2 15 Automated Deduction - George Necula - Lecture 2 16 Derivation Rules for Hoare Triples Derivation Rules for Hoare Logic • Similarly we write ⊢ {A} c { B} when we can derive the • One rule for each syntactic construct: triple using derivation rules ⊢ {A} skip {A} • There is one derivation rule for each command in the language ⊢ {A} c 1 {B} ⊢ {B} c 2 {C} • Plus, the rule of consequence ⊢ {A} c 1; c 2 {C} ⊢ A’ ⇒ A ⊢ {A} c {B} ⊢ B ⇒ B’ ⊢ {A ∧ b} c {B} ⊢ {A ∧ ¬ b} c {B} ⊢ {A’} c {B’} 1 2 ⊢ {A} if b then c 1 else c 2 {B} Automated Deduction - George Necula - Lecture 2 17 Automated Deduction - George Necula - Lecture 2 18 3 Derivation Rules for Hoare Logic (II) Hoare Rules: Assignment • The rule for while is not syntax directed • Example: { A } x := x + 2 {x >= 5 }. What is A? – It needs a loop invariant – A has to imply x ≥ 3 • General rule: ⊢ {A ∧ b} c {A} ⊢ {A} while b do c {A ∧ ¬ b} ⊢ {[e/x]A} x := e {A} • Surprising how simple the rule is ! – Exercise: try to see what is wrong if you make changes to the • But try { A } *x = 5 { *x + *y = 10 } rule (e.g., drop “∧ b” in the premise, …) • A is “*y = 5 or x = y” • How come the rule does not work? Automated Deduction - George Necula - Lecture 2 19 Automated Deduction - George Necula - Lecture 2 20 Example: Assignment The Assignment Axiom (Cont.) • Assume that x does not appear in e • Hoare said: “Assignment is undoubtedly the most Prove that {true} x := e { x = e } characteristic feature of programming a digital • We have computer, and one that most clearly distinguishes it from other branches of mathematics. It is surprising ⊢ {e = e} x := e {x = e} therefore that the axiom governing our reasoning about assignment is quite as simple as any to be found because [e/x](x = e) ≡ e = [e/x]e ≡ e = e in elementary logic .” • Assignment + consequence: • Caveats are sometimes needed for languages with aliasing: ⊢ true ⇒ e = e ⊢ {e = e} x := e {x = e} – If x and y are aliased then ⊢ {true} x := e {x = e} { true } x := 5 { x + y = 10} is true Automated Deduction - George Necula - Lecture 2 21 Automated Deduction - George Necula - Lecture 2 22 Multiple Hoare Rules Example: Conditional • For some constructs multiple rules are possible: D1 :: ⊢ {true ∧ y 0} x := 1 {x > 0} D2 :: ⊢ {true ∧ y > 0} x := y {x > 0} ⊢ ∃ ∧ {A} x := e { x0.[x 0/x]A x = [x 0/x]e} ⊢ {true} if y 0 then x := 1 else x := y {x > 0} (This was the “forward” axiom for assignment •D1 is obtained by consequence and assignment before Hoare) ⊢ {1 > 0} x := 1 {x > 0} ⊢ A ∧ b ⇒ C ⊢ {C} c {A} ⊢ A ∧ ¬ b ⇒ B ⊢ true ∧ y 0 ⇒ 1 > 0 ⊢ ∧ ≥ ⊢ {A} while b do c {B} {true y 0} x := 1 {x 0} ⊢ {C} c {b ⇒ C ∧ ¬ b ⇒ B} •D2 is also obtained by consequence and assignment ⊢ {b ⇒ C ∧ ¬ b ⇒ B} while b do c {B} ⊢ {y > 0} x := y {x > 0} • Exercise: these rules can be derived from the ⊢ true ∧ y > 0 ⇒ y > 0 previous ones using the consequence rules ⊢ {true ∧ y > 0} x := y {x > 0} Automated Deduction - George Necula - Lecture 2 23 Automated Deduction - George Necula - Lecture 2 24 4 Example: Loop Another Example • We want to derive that • Verify that ⊢ {x 0} while x 5 do x := x + 1 { x = 6} ⊢ {A } while true do c { B} • Use the rule for while with invariant x 6 holds for any A, B and c ⊢ x 6 ∧ x 5 ⇒ x + 1 6 ⊢ {x + 1 6} x := x + 1 { x 6 } • We must construct a derivation tree ⊢ {x 6 ∧ x 5 } x := x + 1 {x 6} ⊢ {true ∧ true} c { true } ⊢ ⇒ ⊢ {x 6} while x 5 do x := x + 1 { x 6 ∧ x > 5} A true ⊢ true ∧ false ⇒ B {true} while true do c {true ∧ false} ⊢ • Then finish-off with consequence {A} while true do c { B} ⊢ x 0 ⇒ x 6 • We need an additional lemma: ⊢ x 6 ∧ x > 5 ⇒ x =6 ⊢ {x 6} while … { x 6 ∧ x > 5} ∀ ⊢ ⊢ {x 0} while … {x = 6} c.