Hoare-style program verification

1. Hoare-style program verification K. Rustan M. LeinoGuest lecturer Rob DeLine’s CSE 503, Software EngineeringUniversity 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): intspecification • 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, intstartIndex, intcharCount); 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 <= charCount && 0 <= startIndex;requires startIndex + charCount <= value.Length; ensuresresult == 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 = (Σi | 0≦i<N ･ a[i]); • impl Sum() { N := 0; s := 0 }

9. More about postconditions • Often relate pre-state and post-state • ensures x > 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;ensuresold(n) + 1 = n;method Decrement()modifies only n;ensuresold(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;ensuresold(n) + 1 = n; { a := a + 1 }method Decrement()modifies only n;ensuresold(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;ensuresold(n) + 1 = n; { a := a + 1 }method Decrement()modifies only n;ensuresold(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 Language—Gary 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: < 0.5 s • 80% of all methods: < 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 Run-time exceptions Compile-time error messages Spec# compiler Boogie Code + contracts inSpec# [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 < 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 < y; publicvoid 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 < y; publicvoid 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 Boogieverification

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