Reasoning About Code; Hoare Logic

Slides:



Advertisements
Similar presentations
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Advertisements

ICE1341 Programming Languages Spring 2005 Lecture #6 Lecture #6 In-Young Ko iko.AT. icu.ac.kr iko.AT. icu.ac.kr Information and Communications University.
Reasoning About Code; Hoare Logic, continued
Hoare’s Correctness Triplets Dijkstra’s Predicate Transformers
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 11.
1 University of Toronto Department of Computer Science © 2001, Steve Easterbrook Lecture 10: Formal Verification Formal Methods Basics of Logic first order.
Axiomatic Verification I Prepared by Stephen M. Thebaut, Ph.D. University of Florida Software Testing and Verification Lecture 17.
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.
Copyright © 2006 Addison-Wesley. All rights reserved.1-1 ICS 410: Programming Languages Chapter 3 : Describing Syntax and Semantics Axiomatic Semantics.
ISBN Chapter 3 Describing Syntax and Semantics.
Simple Example {i = 0} j := i * i {j < 100} Can we ‘verify’ this triple? Only if we know the semantics of assignment.
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.
CS 330 Programming Languages 09 / 19 / 2006 Instructor: Michael Eckmann.
1 Semantic Description of Programming languages. 2 Static versus Dynamic Semantics n Static Semantics represents legal forms of programs that cannot be.
Announcements We are done with homeworks Second coding exam this week, in recitation –Times will be posted later today –If in doubt, show up for your regular.
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.
ESC Java. Static Analysis Spectrum Power Cost Type checking Data-flow analysis Model checking Program verification AutomatedManual ESC.
Axiomatic Semantics Dr. M Al-Mulhem ICS
CS 330 Programming Languages 09 / 18 / 2007 Instructor: Michael Eckmann.
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.
Dr. Muhammed Al-Mulhem 1ICS ICS 535 Design and Implementation of Programming Languages Part 1 Fundamentals (Chapter 4) Axiomatic Semantics ICS 535.
CS 330 Programming Languages 09 / 16 / 2008 Instructor: Michael Eckmann.
Describing Syntax and Semantics
Floyd Hoare Logic. Semantics A programming language specification consists of a syntactic description and a semantic description. Syntactic description:symbols.
Reading and Writing Mathematical Proofs
1 Inference Rules and Proofs (Z); Program Specification and Verification Inference Rules and Proofs (Z); Program Specification and Verification.
CSI 3125, Axiomatic Semantics, page 1 Axiomatic semantics The assignment statement Statement composition The "if-then-else" statement The "while" statement.
CS 363 Comparative Programming Languages Semantics.
Reasoning about programs March CSE 403, Winter 2011, Brun.
Program Analysis and Verification Spring 2014 Program Analysis and Verification Lecture 4: Axiomatic Semantics I Roman Manevich Ben-Gurion University.
COP4020 Programming Languages Introduction to Axiomatic Semantics Prof. Robert van Engelen.
Dr. Naveed Riaz Design and Analysis of Algorithms 1 1 Formal Methods in Software Engineering Lecture # 26.
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
C HAPTER 3 Describing Syntax and Semantics. D YNAMIC S EMANTICS Describing syntax is relatively simple There is no single widely acceptable notation or.
Zach Tatlock / Winter 2016 CSE 331 Software Design and Implementation Lecture 2 Formal Reasoning.
CORRECTNESS ISSUES AND LOOP INVARIANTS Lecture 8 CS2110 – Fall 2014.
Reasoning About Code.
Reasoning about code CSE 331 University of Washington.
CSE 331 Software Design & Implementation
Structural testing, Path Testing
Formal Methods in Software Engineering 1
CSE 331 Software Design and Implementation
Testing, conclusion Based on material by Michael Ernst, University of Washington.
CSE 331 Software Design and Implementation
Lecture 5 Floyd-Hoare Style Verification
Axiomatic semantics Points to discuss: The assignment statement
Reasoning about Loops, Conclusion
Specifications, conclusion. Abstract Data Types (ADTs)
Exam 1 Review.
Programming Languages and Compilers (CS 421)
Programming Languages 2nd edition Tucker and Noonan
Semantics In Text: Chapter 3.
Java Reasoning About Code
Section 1: Code Reasoning
Formal Methods in software development
Predicate Transformers
Formal Methods in software development
Program correctness Axiomatic semantics
Program Verification with Hoare Logic
Programming Languages and Compilers (CS 421)
Programming Languages 2nd edition Tucker and Noonan
COP4020 Programming Languages
Presentation transcript:

Reasoning About Code; Hoare Logic

Announcements Homework 0 can now be submitted through Submitty. Due on Wednesday 01/31 at 1:59:59 pm . Questions? HW1 will be up on Wednesday Check course Web page for updates Dafny binaries are available for all OS! https://github.com/Microsoft/dafny Spring 18 CSCI 2600, K. Kuzmin, A Milanova

Forward vs. Backward Reasoning Forward reasoning is more intuitive, just simulates the code Introduces facts that may be irrelevant to the goal Takes longer to prove task or realize task is hopeless Backward reasoning is usually more helpful Given a specific goal, shows what must hold beforehand in order to achieve this goal Given an error, gives input that exposes error Spring 18 CSCI 2600, K. Kuzmin, A Milanova (based on slides by Michael Ernst)

Forward Reasoning: Putting Statements Together Does the postcondition hold? Precondition: x >= 0; z = 0; if (x != 0) { z = x; } else { z = z+1 } Postcondition: z > 0; { x >= 0 && z = 0 } { x > 0 && z = 0 }  { x > 0 && z = x } { x = 0 && z = 0 } { x = 0 && z = 1 }  Therefore, postcondition holds! Spring 18 CSCI 2600, K. Kuzmin, A Milanova (example due to Michael Ernst)

Forward Reasoning With a Loop Does the postcondition hold? Precondition: x >= 0; i = x; z = 0; while (i != 0) { z = z+1; i = i-1; } Postcondition: x = z; { x >= 0 && i = x } Invariant: i + z = x { x >= 0 && i = x && z = 0 } ??? Yes, it holds. Key is to guess a loop invariant. Then prove by induction over the number of iterations of the loop. ??? ??? Spring 18 CSCI 2600, K. Kuzmin, A Milanova (based on the slide by Michael Ernst)

Outline Hoare logic Hoare Triples Rules for backward reasoning Assignment, sequence, if-then-else, method calls Spring 18 CSCI 2600, K. Kuzmin, A Milanova

Hoare Logic Formal framework for reasoning about code Sir Tony Hoare or Sir C.A.R. Hoare Hoare logic Quicksort algorithm Other contributions to programming languages Turing Award in 1980 Framework allows us to formalize and mechanize the process of reasoning about code. Spring 18 CSCI 2600, K. Kuzmin, A Milanova

Hoare Triples A Hoare Triple: { P } code { Q } P and Q are logical statements about program values (in our case, mostly interval constraints on values), and code is program code “{ P } code { Q }” means “if P is true and we execute code, then Q is true afterword” “{ P } code { Q }” is a logical formula, just like “0 ≤ index” Spring 18 CSCI 2600, K. Kuzmin, A Milanova (based on the slide by Michael Ernst)

Examples of Hoare Triples { x>0 } x++ { x>1 } is true { x>0 } x++ { x>-1 } is true { x≥0 } x++ { x>1 } is false. Why? {x>0} x++ {x>0} is ?? {x<0} x++ {x<0} is ?? {x=a} if (x < 0) x=-x { x = | a | } is ?? {x=y} x=x+3 {x=y} is ?? { x≥0 } x++ { x>1 } is a logical formula, just like “x+y = z” or “1 + 2 = 3”. The meaning of “{ x≥0 } x++ { x>1 }” is “If x>=0 and we execute x++, then x>1 will hold”. But this statement is false because when x=1, x++ will be 1 (and hence x>1 won’t hold). Spring 18 CSCI 2600, K. Kuzmin, A Milanova

Backward Reasoning // precondition: ?? x = x + 3; y = 2x; x = 5; // postcondition: y > x { 2(x+3) > 5 } or { x > -1/2 } We know what we want to be true after running the code. What must be true beforehand to ensure that? 2(x+3) > 5 equiv. to 2x > -1 equiv. x > -1/2 2x > 5 y > 5 y > x { 2x > 5 } { y > 5 } Spring 18 CSCI 2600, K. Kuzmin, A Milanova (slide by Michael Ernst)

Rules for Backward Reasoning: Assignment // precondition: ?? x = expression // postcondition: Q Rule: precondition is Q with all occurrences of x in Q replaced by expression // precondition: // precondition: x = y+1; z = z+1; // postcondition: x>0 // postcondtion: z>0 y+1 > 0 z+1 > 0 Spring 18 CSCI 2600, K. Kuzmin, A Milanova (based on the slide by Michael Ernst)

Weakest Precondition Rule derives the weakest precondition // precondition: y+1 > 0 (equiv. y > -1) x = y+1 // postcondition: x>0 (y+1)>0 is the weakest precondition for code x=y+1 and postcondition x>0 Notation: wp stands for weakest precondition wp(“x=expression;”,Q) = Q with all occurrences of x replaced by expression Intuitively, there are many preconditions that can make a Hoare triple with code x = y+1 and postcondition x>0 true. E.g., { y+1 > 0 } x = y+1 { x > 0 } but also { y > 0 } x=y+1 { x > 0 }. This is because y>0 implies y>-1! Spring 18 CSCI 2600, K. Kuzmin, A Milanova

Rule for Assignment { wp(“x=expression”,Q) } x = expression; { Q } Rule: the weakest precondition wp(“x=expression”,Q) is Q with all occurrences of x in Q replaced by expression Spring 18 CSCI 2600, K. Kuzmin, A Milanova

Aside: Weaker and Stronger Conditions “P is stronger than Q” means “P implies Q” “P is stronger than Q” means “P guarantees at least as much as Q” E.g., y > 0 is stronger than y > -1 Which one is stronger? x > 0 && y = 0 or x > 0 && y ≥ 0 0 ≤ x ≤ 10 or 0 ≤ x ≤ 1 x = 5 && y%4 = 2 or x = 5 && y is even Spring 18 CSCI 2600, K. Kuzmin, A Milanova

Aside: Weaker and Stronger Conditions “T => U” means “T implies U” or “T is stronger than U” Let the following be true: P => Q Q => R S => T T => U { Q } code { T } Which of the following are true? (1) { P } code { T } (2) { R } code { T } (3) { Q } code { S } (4) { Q } code { U } { P } code { T } is true because P => Q and { Q } code { T } is true. Intuitively, if Q and code imply T, then certainly P and code will imply T. { R } code { T } is not necessarily true. This is because Q is stronger than R, i.e., Q gives us more guarantees than R. Some of these extra guarantees might be crucial in making { Q } code { T } true. Spring 18 CSCI 2600, K. Kuzmin, A Milanova (based on the slide by Michael Ernst)

Aside: Weaker and Stronger Conditions In backward reasoning, we determine the precondition, given code and a postcondition Q We find the weakest precondition, wp(code,Q) In forward reasoning, we determine the postcondition, given code and a precondition P Normally, we want the strongest postcondition We will be concerned mostly with backward reasoning, but we will do some forward reasoning too. In backward reasoning we want the minimal restrictions our code imposes on surrounding code (callers). We want our code to work at many places. Spring 18 CSCI 2600, K. Kuzmin, A Milanova

Aside: Weaker and Stronger Conditions Goal: Prove that { P } code { Q } is a valid triple Forward reasoning: { P } code derive { Q’ } { Q } Then show Q’ => Q Backward reasoning { P } derive { P’ } code { Q } Then show P => P’ Spring 18 CSCI 2600, K. Kuzmin, A Milanova

Rules for Backward Reasoning: Sequence // precondition: ?? S1; // statement S2; // another statement // postcondition: Q Work backwards: precondition is wp(“S1;S2;”, Q) = wp(“S1;”,wp(“S2;”,Q)) Example: x = 0; y = x+1; // postcondition: y>0 Precondition is {true}, which is the weakest preconditions of all. This means the code imposes no restrictions at all. // precondition: ?? x = 0; // postcondition for x=0; same as // precondition for y=x+1; y = x+1; // postcondition y>0 Spring 18 CSCI 2600, K. Kuzmin, A Milanova (based on the slide by Michael Ernst)

Rule for Sequence { wp(S1,wp(S2,Q)) } S1; // statement { wp(S2,Q) } // find weakest precondition for sequence S1;S2 and Q { wp(S1,wp(S2,Q)) } S1; // statement { wp(S2,Q) } S2; // another statement { Q } Working backwards: precondition is wp(S1;S2, Q) = wp(S1, wp(S2,Q)) Precondition is {true}, which is the weakest preconditions of all. This means the code imposes no restrictions at all. Spring 18 CSCI 2600, K. Kuzmin, A Milanova

Exercise { x + 1 + y > 1 } equiv. to { x + y > 0 } x = x + 1; { x + y > 1 } y = x + y; { y > 1 } Spring 18 CSCI 2600, K. Kuzmin, A Milanova

If-then-else Statement, Example // precondition: ?? if (x > 0) { y = z; } else { y = -z; // postcondition: y>5 (z>5 && x>0) || (z<-5 && x≤0) x > 0 {z>5} {-z>5} y = z y = -z {y>5} {y>5} postcondition: {y>5} Spring 18 CSCI 2600, K. Kuzmin, A Milanova

Rules for Backward Reasoning: If-then-else // precondition: ?? if (b) S1 else S2 // postcondition: Q Case analysis, just as we did in the example: wp(“if (b) S1 else S2”, Q) = ( ( b && wp(“S1”,Q) ) || ( b && wp(“S2”,Q) ) ) Spring 18 CSCI 2600, K. Kuzmin, A Milanova

Rule for If-then-else // wp: ?? if (b) { S1; } else { S2; { Q } (b && wp(S1,Q)) ||( b && wp(S2,Q)) b true false wp(S1,Q) wp(S2,Q) S1 S2 { Q } { Q } { Q } Spring 18 CSCI 2600, K. Kuzmin, A Milanova

Exercise Precondition: ?? z = 0; if (x != 0) { z = x; } else { z = z+1 } Postcondition: z > 0; Spring 18 CSCI 2600, K. Kuzmin, A Milanova (example due to Michael Ernst)

Why Not This Rule? wp(S1,Q) && wp(S2,Q) // wp: ?? if (b) { S1; } else { S2; { Q } b true false wp(S1,Q) wp(S2,Q) Precondition is too strong! In example on slide 17, this too strong precondition cannot be satisfied! S1 S2 { Q } { Q } { Q } Spring 18 CSCI 2600, K. Kuzmin, A Milanova

Why Not This Rule? wp(S1,Q) || wp(S2,Q) // wp: ?? if (b) { S1; } else { S2; { Q } b true false wp(S1,Q) wp(S2,Q) S1 S2 { Q } { Q } { Q } Spring 18 CSCI 2600, K. Kuzmin, A Milanova

Exercise // precondition: ?? y = x + 4 if (x > 0) { y = x*x – 1; } else { y = y+x; } Postcondition: { y = 0 } x = x/y; // What inputs cause Divide-by-zero? Find what input causes divide-by-zero at the last statement. Answer: Precondition: x=1 || x=-2 These are the inputs that cause divide-by-zero error Spring 18 CSCI 2600, K. Kuzmin, A Milanova

If-then-else Statement Review Forward reasoning { P } if (b) { P && b } S1 { Q1 } else { P && b } S2 { Q2 } { Q1 || Q2 } Backward reasoning { (b&&wp(“S1”,Q))||( b&&wp(“S2”,Q)) } if (b) { wp(“S1”,Q) } S1 { Q } else { wp(“S2”,Q) } S2 Spring 18 CSCI 2600, K. Kuzmin, A Milanova (based on the slide by Michael Ernst)

If-then Statement // precondition: ?? if (x > y) { z = x; x = y; } // postcondition: x < y What is the formula for wp(“if (b) S1”, Q) Spring 18 CSCI 2600, K. Kuzmin, A Milanova

Rules for Backward Reasoning: Method Call // precondition: ?? x = foo() // postcondition: Q If method has no side-effects, just like assignment x = Math.abs(y) // postcondition: x = 1 Precondition is y = 1 || y = -1 MORE HERE! Spring 18 CSCI 2600, K. Kuzmin, A Milanova (based on the slide by Mike Ernst, UW)

Summary So Far Intro to reasoning about code. Concepts Hoare triples Specifications, preconditions and postconditions, forward and backward reasoning Hoare triples Rules for backward reasoning Rule for assignment Rule for sequence of statements Rule for if-then-else Method call Spring 18 CSCI 2600, K. Kuzmin, A Milanova