Hoare-style program verification K. Rustan M. Leino Guest lecturer Rob DeLine’s CSE 503, Software Engineering University of Washington 26 Apr 2004.

Slides:



Advertisements
Similar presentations
Hoare-style program verification K. Rustan M. Leino Guest lecturer Rob DeLines CSE 503, Software Engineering University of Washington 26 Apr 2004.
Advertisements

Hoare-style program verification K. Rustan M. Leino Guest lecturer Rob DeLines CSE 503, Software Engineering University of Washington 28 Apr 2004.
Advanced programming tools at Microsoft
Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
The Spec# programming system K. Rustan M. Leino Microsoft Research, Redmond, WA, USA Lunch seminar, Praxis Bath, UK 6 Dec 2005 joint work with Mike Barnett,
Demand-driven inference of loop invariants in a theorem prover
Technologies for finding errors in object-oriented software K. Rustan M. Leino Microsoft Research, Redmond, WA Lecture 1 Summer school on Formal Models.
Technologies for finding errors in object-oriented software K. Rustan M. Leino Microsoft Research, Redmond, WA Lecture 0 Summer school on Formal Models.
Spec# K. Rustan M. Leino Senior Researcher Programming Languages and Methods Microsoft Research, Redmond, WA, USA Microsoft Research faculty summit, Redmond,
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Challenges in increasing tool support for programming K. Rustan M. Leino Microsoft Research, Redmond, WA, USA 23 Sep 2004 ICTAC Guiyang, Guizhou, PRC joint.
In this episode of The Verification Corner, Rustan Leino talks about Loop Invariants. He gives a brief summary of the theoretical foundations and shows.
The Spec# programming system K. Rustan M. Leino Microsoft Research, Redmond, WA, USA Distinguished Lecture Series Max Planck Institute for Software Systems.
Hoare’s Correctness Triplets Dijkstra’s Predicate Transformers
50.530: Software Engineering Sun Jun SUTD. Week 9: Hoare Logic.
Partial correctness © Marcelo d’Amorim 2010.
Axiomatic Semantics The meaning of a program is defined by a formal system that allows one to deduce true properties of that program. No specific meaning.
1 Discrete Structures Lecture 29 Predicates and Programming Read Ch
Predicate Transformers
Program Proving Notes Ellen L. Walker.
Duminda WijesekeraSWSE Program Correctness1 SWSE 623 Program Correctness -Pre-condition, Post-conditions and Loop invariants.
CSE 331 Software Design & Implementation Dan Grossman Winter 2014 Lecture 2 – Reasoning About Code With Logic 1CSE 331 Winter 2014.
1/22 Programs : Semantics and Verification Charngki PSWLAB Programs: Semantics and Verification Mordechai Ben-Ari Mathematical Logic for Computer.
Hoare-style program verification K. Rustan M. Leino Guest lecturer Rob DeLine’s CSE 503, Software Engineering University of Washington 28 Apr 2004.
ESC Java. Static Analysis Spectrum Power Cost Type checking Data-flow analysis Model checking Program verification AutomatedManual ESC.
K. Rustan M. Leino Research in Software Engineering (RiSE) Microsoft Research, Redmond, WA part 0 Summer School on Logic and Theorem-Proving in Programming.
ECI 2007: Specification and Verification of Object- Oriented Programs Lecture 1.
Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
ESC Java. Static Analysis Spectrum Power Cost Type checking Data-flow analysis Model checking Program verification AutomatedManual ESC.
Well-cooked Spaghetti: Weakest-Precondition of Unstructured Programs Mike Barnett and Rustan Leino Microsoft Research Redmond, WA, USA.
Software Verification Bertrand Meyer Chair of Software Engineering Lecture 2: Axiomatic semantics.
Describing Syntax and Semantics
Floyd Hoare Logic. Semantics A programming language specification consists of a syntactic description and a semantic description. Syntactic description:symbols.
Reasoning about programs March CSE 403, Winter 2011, Brun.
COP4020 Programming Languages Introduction to Axiomatic Semantics Prof. Robert van Engelen.
13 Aug 2013 Program Verification. Proofs about Programs Why make you study logic? Why make you do proofs? Because we want to prove properties of programs.
Specifying and verifying programs in Spec# K. Rustan M. Leino Microsoft Research, Redmond, WA, USA Invited talk, PSI 2006 Novosibirsk, Russia 27 June 2006.
Principle of Programming Lanugages 3: Compilation of statements Statements in C Assertion Hoare logic Department of Information Science and Engineering.
Cs7100(Prasad)L18-9WP1 Axiomatic Semantics Predicate Transformers.
CSC3315 (Spring 2009)1 CSC 3315 Languages & Compilers Hamid Harroud School of Science and Engineering, Akhawayn University
Zach Tatlock / Winter 2016 CSE 331 Software Design and Implementation Lecture 2 Formal Reasoning.
CORRECTNESS ISSUES AND LOOP INVARIANTS Lecture 8 CS2110 – Fall 2014.
11/22/2016IT 3271 A formal system:Axioms and Rules, for inferring valid specification x := m; y := n; while ¬(x=y) do if x>y then x := x-y else y := y-x.
Reasoning About Code.
Proving Loops Testing debugging and verification
CSE 331 Software Design & Implementation
Formal Methods in Software Engineering 1
CSE 331 Software Design and Implementation
Hoare-style program verification
Predicate Transforms I
Reasoning About Code; Hoare Logic
Lecture 5 Floyd-Hoare Style Verification
Reasoning about Loops, Conclusion
Programming Languages and Compilers (CS 421)
Programming Languages 2nd edition Tucker and Noonan
Hoare-style program verification
Section 1: Code Reasoning
Formal Methods in software development
Predicate Transformers
Formal Methods in software development
The Zoo of Software Security Techniques
Predicate Transforms I
Program correctness Axiomatic semantics
Program Verification with Hoare Logic
CIS 720 Lecture 3.
CIS 720 Lecture 3.
50.530: Software Engineering
Programming Languages 2nd edition Tucker and Noonan
COP4020 Programming Languages
Presentation transcript:

Hoare-style program verification K. Rustan M. Leino Guest lecturer Rob DeLine’s CSE 503, Software Engineering University of Washington 26 Apr 2004

Is this program correct? — How do we know? int Find(float[] a, int m, int n, float x) { while (m < n) { int j = (m+n) / 2 ; if (a[j] < x) { m = j+ 1 ; } else if (x < a[j]) { n = j-1; } else { return j; } } return - 1 ; }

Making sense of programs Program semantics defines programming language – e.g., Hoare logic, Dijkstra's weakest preconditions Specifications record design decisions – bridge intent and code Tools amplify human effort – manage details – find inconsistencies – ensure quality

State predicates A predicate is a boolean function on the program state Examples: – x = 8 – x < y – m ≦ n ⇒ (∀j | 0≦j<a.length ・ a[j] ≠ NaN) – true – false

Hoare triples For any predicates P and Q and any program S, {P} S {Q} says that if S is started in (a state satisfying) P, then it terminates in Q postcondition precondition

Examples {true} x := 12 {x = 12 } {x < 40 } x := 12 { 10 ≦ x} {x < 40 } x := x+ 1 {x ≦ 40 } {m ≦ n} j :=(m+n)/ 2 {m ≦ j ≦ n} {0 ≦ m < n ≦ a.length ∧ a[m] = x} r := Find(a, m, n, x) {m ≦ r} {false} S {x n + y n = z n }

Precise triples If{P} S {Q} and {P} S {R}, then does {P} S {Q ∧ R} hold?

Precise triples If{P} S {Q} and {P} S {R}, then does {P} S {Q ∧ R} hold? The most precise Q such that {P} S {Q} is called the strongest postcondition of S with respect to P. yes

Weakest preconditions If{P} S {R} and {Q} S {R}, then {P ∨ Q} S {R} holds. The most general P such that {P} S {R} is called the weakest precondition of S with respect to R, written wp(S, R)

Triples and wp {P} S {Q} if and only if P ⇒ wp(S, Q)

Program semantics — skip no-op wp(skip, R) ≡ R wp(skip, x n + y n = z n ) ≡ x n + y n = z n

Program semantics — assignment evaluate E and change value of w to E wp(w := E, R) ≡ R[w := E] wp(x := x + 1, x ≦ 10) ≡x+1 ≦ 10 ≡x < 10 wp(x := 15, x ≦ 10) ≡15 ≦ 10 ≡false wp(y := x + 3*y, x ≦ 10) ≡ x ≦ 10 wp(x,y := y,x, x < y) ≡y < x replace w by E in R

Program semantics — assert if P holds, do nothing, else don't terminate wp(assert P, R) ≡ P ∧ R wp(assert x < 10, 0 ≦ x) ≡0 ≦ x < 10 wp(assert x = y*y, 0 ≦ x) ≡x = y*y ∧ 0 ≦ x ≡x = y*y wp(assert false, x ≦ 10) ≡false

Program compositions If {P} S {Q} and {Q} T {R}, then {P} S ; T {R} If {P ∧ B} S {R} and {P ∧¬B} T {R}, then {P} if B then S else T end {R}

wp(S;T, R) ≡ wp(S, wp(T, R)) wp(x := x+1 ; assert x ≦ y, 0 < x) ≡wp(x := x+1, wp(assert x ≦ y, 0 < x)) ≡wp(x := x+1, 0 < x ≦ y) ≡0 < x+1 ≦ y ≡0 ≦ x < y wp(y := y+1 ; x := x + 3*y, y ≦ 10 ∧ 3 ≦ x) ≡wp(y := y+1, wp(x := x+3*y, y ≦ 10 ∧ 3 ≦ x)) ≡wp(y := y+1, y ≦ 10 ∧ 3 ≦ x+3*y) ≡y+1 ≦ 10 ∧ 3 ≦ x+3*(y+1) ≡y < 10 ∧ 3 ≦ x + 3*y + 3 ≡y < 10 ∧ 0 ≦ x + 3*y Program semantics — sequential composition

wp(if B then S else T end, R) ≡ (B ⇒ wp(S, R)) ∧ (¬B ⇒ wp(T, R)) ≡ (B ∧ wp(S, R)) ∨ (¬B ∧ wp(T, R)) wp(if x < y then z := y else z := x end, 0 ≦ z) ≡(x < y ∧ wp(z := y, 0 ≦ z)) ∨ (¬(x < y) ∧ wp(z := x, 0 ≦ z)) ≡(x < y ∧ 0 ≦ y) ∨ (y ≦ x ∧ 0 ≦ x) ≡0 ≦ y ∨ 0 ≦ x wp(if x≠10 then x := x+1 else x := x + 2 end, x ≦ 10) ≡(x≠10 ∧ wp(x := x+1, x ≦ 10)) ∨ (¬(x≠10) ∧ wp(x := x+2, x ≦ 10)) ≡(x≠10 ∧ x+1 ≦ 10) ∨ (x=10 ∧ x+2 ≦ 10) ≡(x≠10 ∧ x < 10) ∨ false ≡x < 10 Program semantics — conditional composition

Example if (x != null) { n = x.f; } else { n = z-1; z++; } a = new char[n]; true n >= 0 z-1 >= 0 x != null && x.f >= 0 (x != null ==> x != null && x.f >= 0) && (x == null ==> z-1 >= 0)

A good exercise Define change w such that P by giving its weakest precondition

Loops To prove {P} while B do S end {Q} find invariant J and well-founded variant function vf such that: – invariant holds initially: P ⇒ J – invariant is maintained: {J ∧ B} S {J} – invariant is sufficient: J ∧¬B ⇒ Q – variant function is bounded: J ∧ B ⇒ 0 ≦ vf – variant function decreases: {J ∧ B ∧ vf=VF} S {vf<VF}