CS 541 Lecture -*- Outline -*- * Fundamentals of Axiomatic Semantics ** Static Analysis of programs in general want to discover/design/prove properties of programs from text e.g., satisfies its specficication runs in time O(log n) always returns allocations to the free list will not encounter certain errors (safety) e.g., never turns on both motor and brakes at once will eventually accomplish tasks in a queue (liveness) ** Verification: design programs so that they meet their specifications not easy or practical to take an arbitrary program and prove it meets its specification idea: construct program and proof at same time idea: transform specification (or correct program) into an efficient program *** Vs. testing testing can show presence of bugs (as can verification) but cannot prove their absence (except for trival progs) may be possible to combine testing and verification *** Why is verification hard? non-referentially transparent languages so have to reason about state, cannot just use equational logic (one solution: use functional languages) obscure code for efficiency social problems (DeMillo, Lipton, Perlis): in math, people read proofs because they are done at appropriate level of abstraction and are about interesting results in prog. verif., few people read proofs because they are often excessively detailed are not about interesting results Rice's theorem: any non-trivial property of programs is unsolvable certainly verification is, since essentially program equivalence. *** Partial vs. total correctness partial correctness: if the program terminates, then it satisfies spec. total correctness: the program terminates and satisfies spec. ** Hoare Logics *** statements have form: P{S}Q means: if P holds, then after execution of S, Q holds (partial: provided S terminates normally) P and Q assertions about the state (of variables) P is the precondition Q is the postcondition true{S}Q means that Q holds after S P{S}false means that S does not terminate normally soundness of a particular logic proved by using dentotational semantics to show soundness of axioms and inference rules *** axiom schemas: **** assignment: P(E) {x := E} P(x) for all predicates P problems: side effects in E **** built-in procs: R(in) {p(in,out)} Q(out) *** inference rules **** composition: if P{S1}Q, Q{S2}R then P{S1;S2}R **** consequence: if (P==>P1), P1{S}Q1, (Q1==>Q) then P{S}Q can weaken precondition, strengthen postcondition this is the tie-in with the specs of abstract types. ** Modularity of proofs *** Procedures procedures specified with pre and postconditions e.g., sqrt clients assume that procedure meets spec. i.e., spec used to generate new axioms implementor must prove that procedure meets spec. *** Abstract Types objects of type described abstractly (spec of abstract values) e.g., sets described using math sets instead of arrays operations specified with pre and postconditions -stated in terms of each other (algebraic) -stated in terms of the abstract values (if mutation) clients assume operations meet spec. implementor proves operations meet spec. using rep invariant and abstraction function (maps rep to abstract values) ** Verification and type checking *** type checker ensures expression of type T denotes object of type T maintains properties with objects (seals or flags analogy) *** programmer ensures implementation of type T meets specfication type system helps be allowing induction to prove rep invariant *** verifier uses specification of operations of type T for effect of ops know that can treat object abstractly because ops of type T are not invoked outside their domain (i.e., rep invar) moral: type checking is a simple kind of program verification