Hoarestyle program verification

1
Hoare-style program verification

• K. Rustan M. LeinoGuest lecturer

Rob DeLines CSE 503, Software EngineeringUnivers
ity of Washington3 May 2004
2
Programming language

• skip
• x E
• assert B
• S T
• if B then S else T end
• while B do S end

3
Procedural abstraction

• Procedure declaration
• procedure Find(int a, int m, int n, int x) int
• Procedure call
• call r Find(scores, 0, numStudents, 100)
• Procedure implementation
• impl Find(int a, int m, int n, int x) int
  

4
Procedure specifications

• Procedure declaration
• procedure Find(int a, int m, int n, int x)
  int specification
• Procedure call
• call r Find(scores, 0, numStudents, 100)
• Procedure implementation
• impl Find(int a, int m, int n, int x) int
  

Contract between callersand implementations

• Specification spells out the entire contract
• Reason about call in terms of specification only,
  not any particular implementation
• Check implementation against specification only,
  not any particular call site

5
Contracts

• Caller obligations
• Precondition
• Implementation obligations
• Postcondition

6
Informal contract
StringBuilder.Append Method (Char, Int32,
Int32) Appends the string representation of a
specified subarray of Unicode characters to the
end of this instance. public StringBuilder
Append(char value, int startIndex, int
charCount) Parameters value A character
array. startIndex The starting position in
value. charCount The number of characters
append. Return Value A reference to this
instance after the append operation has
occurred. Exceptions
7
Formal contract

• Precondition
• Callers are expected to establish precondition
  before invoking method
• Implementations can assume precondition holds
  on entry

public StringBuilder Append( char value,
int startIndex, int charCount) requires
value ! null (charCount 0 startIndex
0) requires 0 lt charCount 0 lt
startIndex requires startIndex charCount
lt value.Length ensures result this

• Postcondition
• Implementations are expected to establish
  postcondition on exit
• Callers can assume postcondition upon return
  from method invocation

8
A bogus implementation?

• procedure Sum() requires 0?N ensures s (Si
  0?iltN ? ai)
• impl Sum() N 0 s 0

9
More about postconditions

• Often relate pre-state and post-state
• ensures x gt old(x)
• Must say what goes unchanged
• ensures N old(N)
• modifies only s

10
Information hiding anddata abstraction

• class Counter model n int method
  Increment() modifies only n ensures old(n)
  1 n method Decrement() modifies only
  n ensures old(n) n 1

11
Information hiding anddata abstraction

• class Counter model n int private a
  int private b int representation n is a
  b method Increment() modifies only
  n ensures old(n) 1 n a a 1
  method Decrement() modifies only
  n ensures old(n) n 1 b b 1
  

12
Data invariants

• class Counter model n int private a
  int private b int representation n is a
  b invariant 0 ? a ? 0 ? b method
  Increment() modifies only n ensures old(n)
  1 n a a 1 method
  Decrement() modifies only n ensures old(n)
  n 1 b b 1

13
Vision

• Increased programmer productivity and program
  reliability through increased rigor

Record design decisions Utilize automatic
checking Detect errors and improve
maintainability
14
Extended Static Checker for Java (ESC/Java)

• Built at Compaq SRC
• ESC/Java 2 built by Joe Kiniry (U. Nijmegen) and
  David Cok (Kodak)
• Input Java user-supplied annotations
• annotations are subset of JML (Java Modeling
  LanguageGary Leavens, et al., Iowa State U.)
• Annotation language captures programmer design
  decisions
• Powered by program semantics and automatic
  theorem proving
• Performs modular checking

15
ESC/Java demo
16
Program checker design tradeoffs

• Missed errors
• Spurious warnings
• Annotation overhead
• Performance

17
ESC/Java experience annotations

• Capture common design decisions
• Suggested immediately by warnings
• Overhead 4-10 of source code
• 1 annotation per field or parameter
• Most common annotations
• preconditions
• invariants
• Most common things to specify
• non nullity
• container element types

18
ESC/Java experience performance

• 50 of all methods lt 0.5 s
• 80 of all methods lt 1 s
• time limit 300 s
• total time for Javafe (40kloc) 65 min.

19
Tool architecture
Annotated source program
Translator (weakest preconditions)
Verification condition
Valid
Automatic theorem prover
Resource exhausted
Counterexample context
Post processor
Warning messages
20
Spec and Boogie
Compile-time error messages
Run-time exceptions
Boogie
Spec compiler
Code contracts in Spec
Mike Barnett, Robert DeLine, Manuel Fähndrich,
K. Rustan M. Leino, Wolfram Schulte
21
Spec is C extended with

• Non-null types
• Preconditions
• Postconditions
• Object invariants
• Checked exceptions
• ...

22
Boogie Under the hood
MSIL
Boogie
translator
Inferenceengine
BoogiePL
weakest-preconditiongenerator
verification condition
Theoremprover
Warnings
23
Spec Object invariants

• class C int x, y invariant x lt y

Object invariant always holds, except possibly
when the object is exposed
Joint work also with Peter Müller and David A.
Naumann
24
Spec Object invariants

• class C int x, y invariant x lt y
• public void M(T! o) expose (this)
• this.x this.y o.P() this.y

The object invariant may be temporarily violated
here
The object invariant is checked to hold here
25
Spec Object invariants

• class C int x, y invariant x lt y
• public void M(T! o) expose (this)
• this.x this.y o.P() this.y

The exposed/unexposed state of the object is
recorded, so as to detect possible bad re-entrancy
26
Evolution

• C managed code ? Spec non-null types,
  parameter validation ? Boogie verification

27
Summary of lectures

• Hoare triples and weakest preconditions give a
  way to prove a program correct
• Invariants are everywhere
• Procedure specifications
• Tool support for software engineering