CS2393 Topics in Software Verification

1
CS239-3 Topics in Software Verification

• Rupak Majumdar

2
Administration

• Instructor Rupak Majumdar
• Lectures Mon Wed 2-330, 6201 MS
• Office Hours Monday 6pm
• or by appointment
• Office 4531E Boelter Hall
• URL http//www.cs.ucla.edu/rupak/Courses/fall04

3
Overview

• Topics and Goals
• Prerequisites
• Course Structure
• State of the art
• More detailed course information

4
(No Transcript)
5
This Course is about

• Technology for analyzing software
• To make it more reliable
• Testing/Dynamic analysis
• Provide input, run the program, observe output
• Static Analysis
• Examine the source code

6
This course is not about

• Software Process
• Software Project Management
• What programming language to use?
• Todd Millsteins CS294
• How to use the J2EE APIs

7
Goals

• Understand the current state of the art
• In industry
• In research
• Identify research topics
• Where are tools most required?
• Where do current tools fall short?
• How can we integrate static/dynamic analysis?
• Start working on these topics
• Course Projects

8
Prerequisites

• Programming Experience
• Target languages C, C, or Java
• Tools Ocaml
• Programming Languages/Compilers
• Undergraduate level compilers class should be
  enough
• Mathematical Maturity
• The algorithms/techniques will often involve
  greek

9
Evaluation

• This is an advanced graduate class
• No text, but assigned readings from papers
• You are expected to read the papers before you
  come to class
• And participate in discussions
• Major project component

10
Projects

• 2 Person groups
• Identify a large and interesting piece of
  software
• Identify interesting specifications
• Verify that the software meets the specs
• Use available tools
• Most likely, the available tools will fall short
  of your expectations
• Heres where research comes in!
• Figure out new techniques

11
Projects

• I will have a list of possibilities
• You are welcome to suggest your own
• Can use the infrastructure from
• The Blast Model Checker
• Cqual
• Most projects will require both new ideas and
  implementation

12
State of the World

• Standard software development is simple
• Someone writes a program
• Someone runs it and checks that it behaves as
  expected
• Someone decides that it is ok to release

13
Software Development Today
Decision Maker
Developer
Tester
14
Software Development Today
Decision Maker
Developer
Tester
15
Software Development Today
Decision Maker
Ok, everybody calm down, well slip the schedule.
Try again
It doesnt _at_! Compile!
Im done
Developer
Tester
16
Software Development Today
Decision Maker
Now remember, were in this together. Try Again.
It doesnt install!
Im done
Developer
Tester
17
Software Development Today
Decision Maker
Ok, lets have a meeting to straighten out the
spec
It does the wrong thing on half the tests!
Im done
Developer
Tester
Thats coz half your tests are wrong
18
Software Development Today
Decision Maker
Well try again, but please hurry up!
It still fails some tests we agreed on!
Im done
Developer
Tester
19
Software Development Today
Decision Maker
Whoops the world has changed. Heres the new spec
Yes its done!
Im done
Developer
Tester
20
Software Development Today
Decision Maker
Developer
Tester
21
Key Assumptions

• Development and testing must be independent
• Specifications must be explicit
• Specifications evolve
• All resources (programmers, testers, time, money)
  are finite
• Human organizations need decision makers
• Examine each of these aspects

22
Independent Development and Testing

• Testing is basic to any engineering discipline
• Design a drug, a bridge, a car,
• Why?
• Our ability to predict how our creations will
  behave are imperfect
• Well make misteaks, so it is good to chek our
  work

23
Software Engineering

• In what way is software different?
• Folklore
• Programmers are optimists
• Implying that programmers make poor testers
• Economics Programming costs more than testing
• Implying that programming is a higher skill
  area
• How valid are these assumptions, and how much is
  due to the current state of the art in testing?

24
Explicit Specifications

• Software involves multiple people
• At the very least, a programmer and a user
• But usually teams of programmers, testers, users
• Any team effort requires mutual understanding of
  the goals
• A specification
• Otherwise team members inevitably have different
  goals in mind

25
Specifications Change

• Why?
• Many software systems are truly new
• So initial spec changes as problems are
  discovered and fixed, expectations change
• The world changes
• What people want
• The infrastructure, OS,

26
Software Specifications

• Software specifications today are
• In prose
• Imprecise
• Out of date
• Current specifications are not conducive to
  automation
• Not consumable by tools
• Without specs, there is nothing to check

27
Software Specifications

• Without specs, there is nothing to check
• Well, there are specs at the low level
• Types
• Language sanity requirements
• Array bounds, memory dereferences
• Race conditions
• This is where we see automated tools

28
Finite Resources

• Organizations must make trade-offs
• All goals cannot be fulfilled
• Because resources are finite
• s determine the relative costs among goals
• Goals that are hard to quantify pose problems
  e.g., correctness, completeness
• We have 2 months, 5 programmers, and 2 testers.
  Here is a priority list of features. A feature is
  finished when it passes all the tests for that
  feature a programmer does not move on to a new
  feature until all higher priority features are
  finished or allocated to other programmers. We
  start now, and ship whatever we have after 60
  days.

29
Summary of the State of the World

• Software development today depends overwhelmingly
  on the coder/tester model
• Typically over half the cost of developing an
  application is in testing
• And mostly this testing is low tech

30
Well Study

• Technology for analyzing software to make it
  better
• Static analysis
• Examine the source code
• Dynamic analysis
• Examine execution traces
• Testing examine input/output

31
Reliable Engineering
32
Software Engineering
Theory
Physics (mechanics)
Logic
Load, stress, material properties
?
Building blocks
Modeling
Kinematics Equations
?
Analysis
Numerical finite element methods
?
33
Topics in Static Analysis

• Abstract interpretation and Dataflow analysis
• Symbolic execution
• Decision procedures
• Software model checking
• Concentrate on classes of bugs

34
Topics in Dynamic Analysis

• Code coverage
• Test generation
• Test prioritization
• Fault localization
• Invariant Guessing
• Abstractions from tests

35
Operational Semantics
36
Simple Imperative Language

• Lvalues L x L
• Expressions E L n E1 E2 E1 E2 E1
  E2 E1 E2
• Commands C skip C1 C2 let x E in C L
  E if E then C1 else C2 while E do C X
  f(E1,,En) return E
• Programs P sequences of f (x1, , xn) C
• with a special function called main

37
Notes on SIL

• Simple integer and pointer variables
• Structured control flow
• No memory allocation/deallocation
• Call by value
• Assume returns are communicated through a special
  variable

38
Operational Semantics

• Values Val n (integer literals) a
  (addresses)
• State consists of two parts
• An environment ? Var ! Val mapping program
  variables to values
• A store ? Addr ! Val mapping addresses to
  Values
• Commands change the program state

39
State Manipulations

• ?(x) Value of x in environment ?
• ?(a) Content of store ? at address a
• Updates
• ?xv environment same as ? but with x mapped
  to v
• ?av store same as ? but with address a
  containing v
• Operational Semantics
• Expressions ?, ? ² E ? v
• Commands ?, ? ² C ? ?,?

40
Evaluating Expressions
41
Evaluating Commands
42
Evaluating Commands
43
Evaluating Commands
44
Evaluating Commands
45
Axiomatic Semantics

• Operational semantics is an adequate guide for
  implementation
• Homework 1
• For reasoning about programs, axiomatic semantics
  serves better
• Idea
• Program ! Theorem
• Theorem is valid iff Program is correct

46
Axiomatic Semantics

• Consists of
• An assertion language
• Rules for establishing when the assertions hold
• Example assertions
• There is no null dereference
• At function return, returned value gt0
• We shall focus on safety properties that specify
  nothing bad happens (partial correctness)
• We shall ignore liveness properties (something
  good eventually happens) like termination

47
Partial Correctness Assertions

• Assertions will have the form
• AcB
• This means when we start executing the command c
  from a state satisfying A, either the program
  does not terminate, or it terminates in a state
  that satisfies B
• A precondition of c
• B postcondition of c
• Example y 0xzyx z
• AcB also called a Hoare triple
• Partially correct Does not imply termination

48
Total Correctness

• A total correctness assertion AcB says that
  an execution of c from A does terminate in a
  state that satisfies B
• What are A,B?

49
Languages for Assertions

• Specification language to say what correctness
  means
• Should be easy to use, but also expressive
• Must provide syntax and semantics for assertions
• Usual spec languages
• Extensions of first order logic (e.g., in
  traditional program verification)
• Temporal logics (e.g., in hardware verification)
• More exotic (Linear logics, BI logic, )

50
An Assertion Language based on First Order Logic

• Assertions will characterize the state of the
  system
• Fragment of 1st order logic
• Formulas ? T ? A ?Ç? ?Æ? ? 8x.?
  A ) ?
• Atoms A E f(A,,A) E E E E
• Boolean expressions are atoms
• We shall add suitable functions f as the need
  arises
• E.g., sel(p) for dereferencing p
• Reachable(p, q, next) for the predicate p can
  reach q through next fields

51
Semantics of Assertions

• Assertions are state-based
• Characterize the state of execution
• Hence the assertion language allows referring to
  program variables, store
• Semantics of an assertion is a set of program
  states
• Examples of assertions that are not state-based
• x is live,
• whenever x1, it is eventually set to 0

52
Semantics

• Write ?,?² A to mean assertion A holds at state
  ?,?
• Well-defined if ? and ? define all variables and
  memory locations occurring in A
• Define ² inductively
• Omit ? for clarity

53
Definition of truth

• ? ² true for any ?
• ?² e1e2 if ?² e1? n1, ?² e2? n2, and n1 n2
• ?² e1 e2 if ?² e1? n1, ?² e2? n2, and n1 n2
• ?² A1Æ A2 if ?² A1 and ?² A2
• ?² A1Ç A2 if ?² A1 or ?² A2
• ?² A1) A2 if ?² A1 then ?² A2
• ?² 8 x A if for all n2 Z ?² An/x
• ?² 9 x A if there is an n2 Z ?² An/x
• We write A ? ? ² A
• A is a set of program states

54
Partial Correctness

• Formally, AcB if
• 8 ?? 8 ??
• ?,?² A Æ ?,?² c ? ?,?
• implies
• ?,? ² B
• And total correctness says, in addition
• 9 ?,?. ?,?² c? ?,?
• This gives a formal mechanism to check AcB
• Why isnt this enough?

55
Why arent we done?

• The formal mechanism says
• Start the program at every possible state
  satisfying A
• Run the program
• See that on termination, the state satisfies B
• This is exhaustive testing
• Not feasible
• To check 8 x. A we have to iterate over
  infinitely many n2 Z
• Instead, we develop symbolic techniques that
  derive valid assertions from other valid
  assertions
• An assertion A is valid if for all ?,?, we have
  ?,?² A
• Write ² A for valid A
• We write A if we can derive (prove) A
• Ideally, we want A iff ² A

56
Lecture 2
57
Recap

• Want to prove properties of programs
• Defined an assertion language in which to write
  state properties
• Defined its semantics as sets of program states
• Defined partial correctness assertions
• That link assertions across program commands

58
Example GCD

• xm, y n
• while (x? y) do
• if x y then y y x else x x y
• x gcd(m,n)

59
Partial Correctness

• Formally, AcB if
• 8 ?? 8 ??
• ?,?² A Æ ?,?² c ? ?,?
• implies
• ?,? ² B
• And total correctness says, in addition
• 9 ?,?. ?,?² c? ?,?
• This gives a formal mechanism to check AcB
• Why isnt this enough?

60
Why arent we done?

• The formal mechanism says
• Start the program at every possible state
  satisfying A
• Run the program
• See that on termination, the state satisfies B
• This is exhaustive testing
• Not feasible
• To check 8 x. A we have to iterate over
  infinitely many n2 Z
• Instead, we develop symbolic techniques that
  derive valid assertions from other valid
  assertions
• An assertion A is valid if for all ?,?, we have
  ?,?² A
• Write ² A for valid A
• We write A if we can derive (prove) A
• Ideally, we want A iff ² A

61
² vs

• ² A if for all program states ?,?, we have ?,?² A
  (validity for an assertion)
• A if in our proof system we can prove A holds
• Sound proof system A implies ² A
• Complete proof system ² A implies A

62
Where are we?

• Have a language to write assertions
• Know when an assertion is true
• Will give a symbolic method to derive assertions

means
?,? ² A, ² AcB
A, AcB
sound
symbolic derivation
complete
A, AcB
63
Derivation Rules for Assertions

• Usual ones from 1st order logic

64
Derivation Rules for Hoare Triples

• Write -AcB when we can derive the triple
  using derivation rules
• One rule for each command in the language
• Plus, rule of consequence

65
Derivation Rules for Hoare Triples
66
Rule for while

• Rule for while is not syntax directed
• Requires a loop invariant

67
Rule for Assignment

• Example Axx2x 5. What is A?
• A must imply x 3
• Rule
• Surprisingly simple!
• But does not deal with memory
• A x 5 xy 10
• Answer xy or y 5
• But this rule only gives y5

68
A Little Practice

• Show that truexexe if x does not appear in
  e
• We have eexexe by rule of assignment
• Also true) ee, use rule of consequence

69
Multiple Hoare Rules

• Multiple rules are possible
• Forward axiom of assignment
• Alternate Rules for while

70
Axiom of Assignment

• Backward axiom of assignment
• Notice that we can substitute for x_0 in the
  antecedent! This gives the simple form
• Sometimes this is not good Flanagan and Saxe 01

71
Examples

• Derive
• true if y 0 then x1 else xyxgt 0
• x 0 while x 5 do xx1x6
• A while true do c B (for any A,B,c)
• GCD (Loop invariant gcd(x,y)gcd(m,n))

72
Function Calls

• If there is no recursion, we can inline
• In general, assume each function f has a Pref and
  a Postf
• For each function, check separately that
  PrefCfPostf

73
Memory and Side Effects

• Recall that Ax5xy10
• A should be xy or y5
• But we get y5
• Assertions do not have side effects
• We should remove side effects while creating the
  theorem!
• How can we do this without precise alias
  information?
• Trick Postpone alias questions

74
Memory and Side Effects

• Model memory state as a symbolic map from
  addresses to values
• For memory state M, and address expression E,
  write
• Sel(M,E) content of cell E of M
• Upd(M,E,v) New memory state obtained from M by
  writing v at address E
• We allow variables to range over memory states
  (so we can quantify over possible memory states)
• Use special variable ? to refer to current memory
  state

75
Formal Semantics

• Values v n a ? (memory values)

76
Evaluating Memory Expressions
77
Hoare Rules

• Use memory expressions in Hoare rules
• A memory write changes the memory state
• Reason about memory expressions using McCarthys
  axioms
• Sel(upd(M,E1,E2),E3) E2 if E1E3
• 
  sel(M,E3) if E1? E3

78
Example

• Ax 5xy 10
• Then A (x y 10)upd(?,x,5)/?
• (sel(?,x) sel(?,y) 10)upd(?,x,5)/?
• sel(upd(?,x,5),x) sel(upd(?,x,5),y) 10
• 5 sel(upd(?,x,5),y) 10
• if xy then 5510 else 5sel(?,y)10
• xy Ç 5 y 10
• Requires theorem proving using McCarthys axioms

79
Program Verification

• This was the grand dream of program correctness
• For a program,
• Write correctness conditions as Hoare triples
• Use a theorem prover to derive the Hoare triples
• This failed!

80
Wrinkles

• When do you use the rule of consequence? How do
  you prove the implications
• What loop invariants to use? What are suitable
  function pre and postconditions?
• No one writes code with these invariants
• Biggest stumbling block
• Then there is the issue of automatic theorem
  proving
• Manual proofs just do not scale
• Other objections Perlis

81
Where are we?

• Have a language to write assertions
• Know when an assertion is true
• Have a symbolic method to derive assertions

means
?,? ² A, ² AcB
A, AcB
sound
symbolic derivation
complete
A, AcB
82
Soundness

• If AcB then ² AcB
• Equivalently,
• For all ?,?, if ?,?² A
• and D ?,? ² c? ?,?
• and H AcB
• then ?,?² B

83
Completeness

• Is it true that ² AcB implies -AcB
• In general, the answer is no (think
  incompleteness theorem!)
• There are valid statements about programs that we
  cannot prove with Hoare rules
• Relative completeness
• If the underlying logic is complete (that is, ² A
  implies A) then Hoare logic is complete

84
(Relative) Completeness

• Dijkstras Idea
• To verify AcB, find out all A such that
• ² AcB, call this set Pre(c,B)
• Verify that for one A2 Pre(c,B), A) A
• Order assertions by implication

true
false
)
Pre(c,B)
weak
strong
Weakest precondition WP(c,B)
A
85
Proof Idea

• Suppose we can compute Wp(c,B) s.t.
• Wp is a precondition Wp(c,B)cB
• Wp is the weakest precondition
• If ² AcB then ² A ) Wp(c,B)
• Then derive AcB from
• A ) Wp(c,B)
• Wp(c,B)cB
• by rule of consequence
• Notice we need that whenever ² A then A
• This is where completeness of the underlying
  logic comes in

86
Weakest Precondition

• Define Wp(c,B) inductively on c
• Based on Hoare rules

87
WP for loops

• Start with the observation
• while e do c if e then c while e do c else
  skip
• Let w while e do c, and Wwp(w,B)
• Then
• W b) wp(c,W) Æ b ) B
• This is a recursive equation
• Domain theory tells us how to solve such
  equations
• What is a domain for assertions?

88
Lattice for Assertions

• Bottom (least information) true
• Ordering A A iff ² A) A
• (Implication ordering)
• Completeness Take a chain
• A1 A2
• Let Æ Ai be the infinite conjunction (Note this
  is not in our language!)
• Æ Ai is the least upper bound (check!)
• Can Æ Ai be expressed in our language of
  assertions?
• In many cases, yes. We assume that it can.

89
Solving Recursive Equations over Lattices

• Basic Idea Let z ? F(z) be a monotonic and
  continuous function on a lattice
• Then the (least) fix point a F(a) is given by
  the l.u.b. of the chain Fi(?), i 0
• In our case, let F(A) b) wp(c,A) Æ b) B
• Check that F is monotonic and continuous
• Solution Æ Fi(true)

90
Weakest Preconditions

• Define a family of wps
• Wpk(w,B) WP on which the loop, if it terminates
  in k or fewer steps, terminates in B
• Wp0(w,B) E ) B
• Wp1 E ) Wp(c,Wp0) Æ E ) B
• Wp(w,B) Æk 0 Wpk
• Question Is Wpk ) Wpk-1?
• In general, Wp is impossible to compute
• Can we find a sufficient condition?

91
Example 1

• Consider Wp(while x 5 do xx1, x 7)
• Wp(xx1,A) x1/xA
• Wp0 (x 5)) x 7 x? 6
• Wp1 x 5 ) x1? 6 Æ Wp0 x? 5,6
• Wp2 x? 4,5,6
• Wp x 7

92
Example 2

• Consider Wp(while x 5 do xx1, x 7)
• Wp(xx1,A) x1/xA
• Wp0 (x 5)) x 7 x 5
• Wp1 x 5 ) x1 7 Æ Wp0 x 5
• Wp x 5

93
Sufficient Conditions

• Recall what we want to do
• We shall construct a verification condition
  VC(c,B)
• Assume loops have loop invariants
• VC is stronger than WP
• But hopefully sufficient A) VC ) WP

true
false
)
Pre(c,B)
weak
strong
Weakest precondition WP(c,B)
A
Verification Condition VC(c,B)
94
Verification Conditions

• Factor out the hard work
• Loop invariants
• Function pre and post conditions
• Assume programs are annotated with these specs
• i.e., while I e do c / I is the loop invariant
  /
• I must hold every time before e is checked

95
Invariants are not easy

• xm, y n
• while (x? y) do
• if x y then y y x else x x y
• x gcd(m,n)
• Quicksort,

96
VC Generation

• Similar to wp
• VC(skip,B) B
• VC(c1c2,B) VC(c1,VC(c2,B))
• VC(if b then c1 else c2,B)
• b) VC(c1,B) Æ b ) VC(c2,B)
• VC(let xe in c,B) e/xVC(c,B)
• VC(e1e2, B) upd(?,e1,e2)/?B

97
VC Generation while

• VC(while I b do c, B)
• I Æ / I holds on entry /
• (8 x1..xn.I ) (b) VC(c,I) Æ
• / I is preserved by an arbitrary
  iteration /
• b ) B)
• / B holds when the loop terminates at
  an arbitrary iteration /
• )
• I is the loop invariant
• x1,,xn are all variables modified by c

98
VC for Function Calls

• VC(xf(e1,,en),B)
• PrefE/xi Æ 8?8 f Postf ) Bf/x
• Check the precondition (with actuals for formals)
• Assume that memory and return value are changed
• Check that function postcondition is stronger
  than B

99
Soundness and Completeness

• Soundness VC(c,B) ) WP(c,B)
• Completeness is trickier
• Show that it is possible to choose loop
  invariants such that WP(c,B) ) VC(c,B)

100
Program Verification

• Given program P with loop invariants and function
  pre and post conditions
• Generate VC
• Use a theorem prover to prove VC
• ESC/Java
• Wrinkles Annotations!!
• Annotation overhead too high
• For complex correctness properties, theorem
  prover is no longer automatic

101
Conclusion

• The grand vision of automatic program correctness
  has been abandoned
• Completeness was abandoned from logic
• Sound analyses still require too much work
• But many of the techniques are still very useful
• Weakest preconditions
• Verification conditions
• If we could automatically construct those darned
  loop invariants!

102
Forward VC Generation

• Our definition of VC computes VC backwards
• Works well for structured languages
• VC can also be computed in a forward direction
• Also works for unstructured languages
• Also called symbolic execution

103
Basic Intuition

• We shall use the forward assignment rule, keeping
  the substitutions explicit
• Set up a symbolic evaluation state
• ?Var ! SymExps
• ?(x) symbolic value of x in symbolic state ?
• ?xe updated state
• Write ?(e) as the symbolic expression obtained by
  replacing x with ?(x) in e

104
Constraints

• So far, it was like operational semantics
• Additionally, we keep track of the encountered
  constraints
• Two cases
• Invariant annotations
• No annotations

105
Control Flow Automata

• For convenience, we shall work with a minimal
  language of operations together with a control
  flow graph
• Operations Syntax
• skip x e e1 e2 assume(e) xf()
  return inv e
• Graph
• Directed graph, nodes correspond to program
  locations
• Edges with program operations
• Edges labeled with operations
• Graph encodes control flow

106
Notes on Operations

• assume (p) has the semantics
• If p then skip else stop
• i.e., program execution continues to the next
  node if the current state satisfies p
• Can encode if statements as
• assume(p) c1
• assume( p) c2
• inv p is an annotation p is an invariant
• assert (p) has the semantics
• If p then skip else abort
• Says p must be true at the current program point

107
Control Flow Automata

• Assume G (V,E)
• Write (v,op,v) 2 E
• If edge (v,v) is labeled with operation op
• Assume v0 is the function entry point

108
Forward VC generation

• Define a VC function as an interpreter
• VC V SymbolicState InvariantState !
  Assertion
• InvariantState is a subset of edges
• VC(v,?,Inv) Ç(v,op,v)2 E EVC((v,op,v), ?,
  Inv)
• Compute EVC by cases
• EVC((v,skip,v),?,Inv) VC(v,?,Inv)
• EVC((v,xe,v),?,Inv) VC(v,?x?(e),Inv)
• EVC((v,e1e2,v),?,Inv) VC(v,??upd(?,?(e1)
  ,?(e2)),Inv)
• EVC((v,assume(p),v),?,Inv) ?(p) Æ VC(v,?,Inv)

109
Forward VC generation

• Compute EVC by cases
• EVC((v,xf(),v),?,Inv) ?(Pref) Æ 8
  a1,,am.?(Postf)) VC(v,?,Inv)
• where y1,,ym are modified by f,
• a1,,am are fresh, and
• ? ?y1a1,,ymam
• EVC((v,return,v),?,Inv) ?(Post(currentf))

110
Invariants

• There are two cases
• 1. We see the invariant for the first time
• (v,inv p, v) ? Inv
• Let y1,,ym be the variables that could be
  modified on a path from v back to v
• Let a1am be fresh parameters
• EVC((v,inv p,v),?,Inv)
• ?(p) Æ 8 a1am. ?(p) ) VC(v,?,Inv (v,inv
  p,v))
• where ? ?y1a1,,ymam

111
Invariants

• 2. We see the invariant for the second time
• (v,inv p, v) \in Inv
• EVC((v,inv p,v),?,Inv) ?(p)
• (Like a function return)

112
Putting it Together

• If each (backward branching) join point has an
  invariant annotation, this terminates.
• Let x1xn be all the variables
• Let a1an be fresh parameters
• ?0 xi? ai
• For all functions f in the program, compute
• 8 a1an. ?0(Pref)) VC(v0,?0,)
• If all these predicates are valid, then

113
Putting it Together

• If all these predicates are valid, then
• If you start the program by invoking any f in a
  state that satisfies Pre_f the program will
  execute such that
• At all inv p, the p holds
• If the function returns then Post_f holds
• Assume-guarantee reasoning
• Assume the behavior of each function
• Check each function, with assumptions about its
  environment

114
Example
inv(x 6)

• Pre x 0
• Loop inv x 6
• if xgt5 goto End
• x x1
• Goto Loop
• End return
• Post x 6

asm(xgt5)
asm(x 5)
xx1
return
skip
115
Example
inv(x 6)

• 8 a.a 0) /Pre/
• a 6 Æ / inv /
• 8 a.a 6)
• VC(v,?,e)

v
asm(xgt5)
asm(x 5)
xx1
return
skip
116
Example
inv(x 6)

• 8 a.a 0) /Pre/
• a 6 Æ / inv /
• 8 a.a 6)
• ((agt5Æ a6)
• Ç / If /
• (a 5 Æ
• a1 6))

v
asm(xgt5)
asm(x 5)
xx1
return
skip
117
VC and Invariants

• Consider
• x 0 while I x 5 do x x6
• VC x 0) I(x) Æ
• 8 x.I(x))
• (xgt5Æ x6) Ç (x 5Æ I(x1))
• There are three requirements
• I holds on entry 8 x.x 0) I(x)
• Preserved by the body 8 x.I(x)Æ x 5 ) I(x1)
• Useful (proves the postcondition) 8 x.I(x)Æ xgt5 )
  x6
• Check that I(x) x 6 satisfies all three
  requirements

118
Problems with VCs

• Invariant annotations
• VC can be exponential in size
• There can be a conjunct for every program path
• if(xlt0) x-x if (x 10) xx10 else xx-10
• VC
• xlt0 Æ x 10 ) P(-x10)
• xlt0 Æ xgt10) P(-x-10)
• x 0 Æ x 10) P(x10)
• x 0 Æ xgt10 ) P(x-10)
• Substituting at assignments can make formulas
  very large
• X0 y y
• X1 X0X0
• Xn Xn-1 Xn-1

119
Symbolic Execution as a Debugging Tool

• Suppose there are no annotations
• Can still use symbolic execution as a debugging
  tool
• Sacrifice completeness for usability
• Drop paths
• At a branch point, choose one path
• Iterate through loops a fixed number of times
• At each point, check current symbolic state for
  assertion violations
• Prefix, variations of ESC, some analyses in gcc

120
Memory Simplifications

• McCarthys axioms simpified
• sel(upd(M,E1,E2),E3)
• E2 if E1 obviously E3
• sel(M,E3) if E1 obviously? E3
• fresh p otherwise
• The meaning of obviously varies
• Addresses of distinct globals different
• Syntactic checks

121
Conclusion

• Verification conditions
• Symbolically express the semantics of the program
• Independent of language
• Can be computed forward or backward
• Problem for sound analysis requires invariants