CSE 3341.03 Winter 2008Introduction to Program Verification

for-loops; review

Sec. 9.9 fundamental differences between for-

loops and while-loops? why not do everything with while-loops?

what's the connection with simple recursion?

transforming for-loop to a while-loop

for (int V = Initial; V < Limit; V++) S; translates to:int V = Initial; while(V < Limit ) {S ; V++;} need to add an invariant.

assume if loop is entered it exits with V = Limit (no break; Limit unmodified)

What is the consequence for calculating a wp?

compare scenarios: symbex vs. wp

symbex: title: verify a code segment (assignment,

conditional, procedure statements) context (what's given?) proof obligations? background? correctness of simplification

rules, Well-Behaved Expression assumption

wp scenario, p. 53 title: verify a code fragment (any statement for

which wp(S, Q) or pre(S, Q) is implemented) context: optional pre-condition, code-segment

and a goal or desired post-condition; propose an invariant for each loop statement

proof obligations: ?

exam: closed book, two hours exam: closed book, two hours

April 10, 7 PM, Chemistry Building 120

Father Sarducci: http://www.cs.washington.edu//info/videos/asx/5minuteU.asx

see link on the Extras page:

http://www.cse.yorku.ca/course_archive/2007-08/W/3341/extras.html

review

Software verification: "Sarducci" version

Introductory: verification is spell-checking for program logic.

Advanced: “functional good; procedural bad”.

Ch. 0 programming errors can be disastrous

testing isn’t good enough• if we’re serious about programming quality, we will

need formal verification methods• tedious (lots of intricate detail)• hard to do correctly

solution? automation -- hence verification tools

Ch. 1 propositional calculus is fundamental

why do we replace logical symbols with English words?enables automated calculation of boolean expressions

classification of propositions: tautology, satisfiable, contingent, contradictionwhy is this of interest?

Ch. 2 (tautology) we can automate the testing whether a

proposition is a tautology using the method of a truth table:

• requires possibly exhaustive search -- of what?• biased towards detecting falsity

automating the truth-table method just requires entering rules for all the logical operators allowed in the calculus

rule-based programming control structure is weak or non-existent

structure of the data selects the rule

which tests it

iteration replaced by recursion

do we need anything else besides

tautology-checking to classify props? can use tautology-checking to check for

contingency or contradiction

nice feature of the calculation: if not a tautology, we get a counter-example

Ch. 3 (wang) different data structure gives a more useful algorithm

• what is the datastructure? wang biased towards truth

• allows complex descriptions, using terms• term is a very versatile data structure for representing math.

concepts, i. e. for symbolic computation in what sense, is wang a syntactic method as opposed

to the truth-table’s semantic method?

how is proof different from implication?

sequents wang implements tautology-checkingby converting the input to a sequent:

{conjunction} >> {disjunction}• using special rules to reduce the input to sets of

non-logical terms

terms Lisp implements terms as lists

advantage: functor can be a variable• (2nd order logic)

disadvantage: pattern-matching is more complex

Prolog implements lists as terms• advantage: very good fit with pattern-matching

Ch. 4 (simplify) add math. knowledge in form of rewrite or

simplification rules theories = collections of inter-related rules

use canonical forms to recognize identities syntactically

use pattern-variables and rewriting to capture semantic relationships

e. g. X = X ->> true.

pattern variables Note: pattern variables act like universally

quantified variables allows us to extend prop. calculus to FOL or

predicate calculus

example: (x) P(x). can be written as p(X) ->> true.

Ch. 5 (prover, induction) use simplification to evaluate symbolic

expressions involving functions on ADTs verify propositions about ADTs by combining

tautology checking and simplification = prover (what else does prover add?)

in general, computable functions are recursively definable on a domain of ADTs; for some recursive definitions (we called them simple recursion) we can use induction to verify that the recursive definition is correct relative to another non-recursive definition

recursive definition describes how the function would be computed in a functional programming language

the non-recursive definition is usually an algebraic expression.

mathematical induction the proof that a recursive function is

correctly defined rests on the principle of inductiona rule of inference: given a premise

(proposition) infer another proposition e. g. P(0) and (0 < n and P(n-1) implies P(n)

|- P(n).

extensions from simple recursion

to tail-recursion

verification by transformation what’s the advantage?

• for-loops transform easily into tail-recursion (Ch. 9: for-loops transform into restricted

while-loops)

from integers to recursive ADTs key idea: to use induction to prove things about an ADT,

we need, given an initial object, to be able to compute a smaller object . .

and by repeating this recursively, we get to the base (non-recursive) case

key idea: any verification scenario determines a set of proof-obligations to be discharged:

either by calculation or by a “manual” proof. tools assist in organizing this process and determining

whether enough theory is provided to complete the proofs

scenarios many types of verifications key idea: any verification scenario determines a specific

set of proof-obligations to be discharged: either by calculation or by a “manual” proof.

tools assist in organizing this process and determining whether enough mathematical theory and definitions are provided to complete the proofs

Ch. 6 varieties of verification

implementation of one ADT by another (simpler) one.• example: use arrays (non-recursive datatype) to implement

stacks or lists. implementation of a concrete ADT (Circle) as an instance of an

abstract one (Shape)• verify that the Circle satisfies the properties of a Shape

(how?) implementation of a complex object as a composition of simple

objects• logical circuit

Ch. 7 specifications are annotations that describe

contracts in the form of pre- and post-conditions we can derive these “by hand” from code, using our

informal understanding of what the code is supposed to do

specifications aren’t absolute• they’re relative to somewhat fuzzy background assumptions:

that functions are well-behaved (no side effects, etc.); that expressions are assumed to be restricted to values in the domains of the expressions’ functions; that all expressions terminate

Ch. 8 we can compute post-conditions by symbolic

execution (symbex); verify a code segment by showing that the calculated (descriptive) post-condition implies a given goal specification

but disadvantages?

Ch. 9 assume every code segment has a goal (a purpose) use wp to verify that the segment achieves the goal, relative to a pre-

condition: either true, the post-condition of a previous segment, or a contractual requirement compute a pre-condition pre(“S;”, Goal), preferably the most general

(weakest pre-condition) wp(“S;”) that is guaranteed to achieve the goal

• working backwards has advantages;• for loop-free code, wp can be computed using definitions of wp for

standard statement types; loops are more complicated• what are the proof-obligations for verifying {P} “while(B) S;” {Goal}?