Reasoning About Code.

Slides:



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

In this episode of The Verification Corner, Rustan Leino talks about Loop Invariants. He gives a brief summary of the theoretical foundations and shows.
Reasoning About Code; Hoare Logic, continued
Hoare’s Correctness Triplets Dijkstra’s Predicate Transformers
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 Design by Contract Building Reliable Software. 2 Software Correctness Correctness is a relative notion  A program is correct with respect to its specification.
Predicate Transformers
Program Proving Notes Ellen L. Walker.
1 Semantic Description of Programming languages. 2 Static versus Dynamic Semantics n Static Semantics represents legal forms of programs that cannot be.
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
Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
Dr. Muhammed Al-Mulhem 1ICS ICS 535 Design and Implementation of Programming Languages Part 1 Fundamentals (Chapter 4) Axiomatic Semantics ICS 535.
4/17/2017 Section 3.6 Program Correctness ch3.6.
Describing Syntax and Semantics
Floyd Hoare Logic. Semantics A programming language specification consists of a syntactic description and a semantic description. Syntactic description:symbols.
Proving Program Correctness The Axiomatic Approach.
Proving Program Correctness The Axiomatic Approach.
Reading and Writing Mathematical Proofs
1 Program Correctness CIS 375 Bruce R. Maxim UM-Dearborn.
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.
Reading and Writing Mathematical Proofs Spring 2015 Lecture 4: Beyond Basic Induction.
Reasoning about programs March CSE 403, Winter 2011, Brun.
Chapter 3 Part II Describing Syntax and Semantics.
Semantics In Text: Chapter 3.
COP4020 Programming Languages Introduction to Axiomatic Semantics Prof. Robert van Engelen.
Static Techniques for V&V. Hierarchy of V&V techniques Static Analysis V&V Dynamic Techniques Model Checking Simulation Symbolic Execution Testing Informal.
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.
Reasoning and Design (and Assertions). How to Design Your Code The hard way: Just start coding. When something doesn’t work, code some more! The easier.
CORRECTNESS ISSUES AND LOOP INVARIANTS Lecture 8 CS2110 – Fall 2014.
Math/CSE 1019C: Discrete Mathematics for Computer Science Fall 2012
Loop Structures.
Reasoning about code CSE 331 University of Washington.
Proving Loops Testing debugging and verification
CSE 331 Software Design & Implementation
CSE 331 Software Design and Implementation
Looping and Repetition
Copyright © Cengage Learning. All rights reserved.
Reasoning About Code; Hoare Logic
Lecture 5 Floyd-Hoare Style Verification
Axiomatic semantics Points to discuss: The assignment statement
Programming Languages and Compilers (CS 421)
Programming Languages 2nd edition Tucker and Noonan
Java Programming Loops
Semantics In Text: Chapter 3.
Chapter 6: Repetition Statements
Section 1: Code Reasoning
Predicate Transformers
Axiomatic Semantics Will consider axiomatic semantics (A.S.) of IMP:
Java Programming Loops
The Zoo of Software Security Techniques
Program correctness Axiomatic semantics
Program Verification with Hoare Logic
Programming Languages and Compilers (CS 421)
50.530: Software Engineering
Programming Languages 2nd edition Tucker and Noonan
COP4020 Programming Languages
Looping and Repetition
Presentation transcript:

Reasoning About Code

Reasoning about code Determine what facts are true during execution x > 0 for all nodes n: n.next.previous == n array a is sorted x + y == z if x != null, then x.a > x.b Applications: Ensure code is correct (via reasoning or testing) Understand why code is incorrect

Forward reasoning You know what is true before running the code What is true after running the code? Given a precondition, what is the postcondition? Applications: Rep invariant holds before running code Does it still hold after running code? Example: // precondition: x is even x = x + 3; y = 2x; x = 5; // postcondition: ??

Backward reasoning You know what you want to be true after running the code What must be true beforehand in order to ensure that? Given a postcondition, what is the corresponding precondition? Application: (Re-)establish rep invariant at method exit: what requires? Reproduce a bug: what must the input have been? Example: // precondition: ?? x = x + 3; y = 2x; x = 5; // postcondition: y > x How did you (informally) compute this?

Forward vs. backward reasoning Forward reasoning is more intuitive for most people Helps you understand what will happen (simulates the code) Introduces facts that may be irrelevant to goal Set of current facts may get large Takes longer to realize that the task is hopeless Backward reasoning is usually more helpful Helps you understand what should happen Given a specific goal, indicates how to achieve it Given an error, gives a test case that exposes it

Reasoning about code statements Goal: Convert assertions about programs into logic General plan Eliminate code a statement at a time Rely on knowledge of logic and types There is a (forward and backward) rule for each statement in the programming language Loops have no rule: you have to guess a loop invariant Jargon: P {code} Q P and Q are logical statements (about program values) code is Java code “P {code} Q” means “if P is true and you execute code, then Q is true afterward” Is this notation good for forward or for backward reasoning?

Forward reasoning example assert x >= 0; i = x; // x0 & i = x z = 0; // x0 & i = x & z = 0 while (i != 0) { z = z + 1; i = i –1; } // x0 & i = 0 & z = x assert x == z;  What property holds here?  What property holds here?

Backward reasoning Technique for backward reasoning: Compute the weakest precondition (“wp”) There is a wp rule for each statement in the programming language Weakest precondition yields strongest specification for the computation (analogous to function specifications)

Precondition = Q with all (free) occurrences of x replaced by e Assignment // precondition: ?? x = e; // postcondition: Q Precondition = Q with all (free) occurrences of x replaced by e Example: // assert: ?? x = x + 1; // assert x > 0 Precondition = (x+1) > 0 We write this as wp for “weakest precondition” wp(“x=e;”, Q) = Q with x replaced by e Free is a technicality that you should not worry about

Method calls // precondition: ?? x = foo(); // postcondition: Q If the method has no side effects: just like ordinary assignment If it has side effects: an assignment to every var in modifies Use the method specification to determine the new value

Composition (statement sequences; blocks) // precondition: ?? S1; // some statement S2; // another statement // postcondition: Q Work from back to front Postcondition = wp(“S1; S2;”, Q) = wp(“S1;”, wp(“S2;”, Q)) Example: x = 0; y = x+1; // postcondition: y > 0 Should be wp(S1; S2, Q) = wp(S1, wp(S2,q)) Remember, we are working backwards through code Do this on the board E.g., wp(“x = 0; y = x + 1”, y > 0) = wp(“x = 0”, wp(“y = x + 1”, y > 0) = wp(“x = 0”, x + 1 > 0) = 1 > 0 = true

Essentially case analysis wp(“if (b) S1 else S2”, Q) = If statements // precondition: ?? if (b) S1 else S2 // postcondition: Q Essentially case analysis wp(“if (b) S1 else S2”, Q) = ( b  wp(“S1”, Q) ∧ b  wp(“S2”, Q) ) Over-simplifying a bit, assuming evaluation of b has no side effects

= wp(“if (x==0) {x = x+1;} else {x = x/x}”, x  0) If, an Example // precondition: ?? if (x == 0) { x = x + 1; } else { x = (x/x); } // postcondition: x  0 Precondition = wp(“if (x==0) {x = x+1;} else {x = x/x}”, x  0) = ( x = 0wp(“x = x+1”, x  0) & x  0  wp(“x = x/x”, x  0) ) = (x = 0  x + 1  0) & (x  0  x/x  0) = 1  0 & 1  0 = true Note: == a Java construct = overload. In code assignment, in assertions a logical operator

Reasoning About Loops A loop represents an unknown number of paths Case analysis is problematic Recursion presents the same issue Cannot enumerate all paths That is what makes testing and reasoning hard

Reasoning About Loops: values and termination // assert x  0 & y = 0 while (x != y) { y = y + 1; } // assert x = y 1) Pre-assertion guarantees that x  y 2) Every time through loop x  y holds – and if body is entered, x > y y is incremented by 1 x is unchanged Therefore, y is closer to x (but x  y still holds) 3) Since there are only a finite number of integers between x and y, y will eventually equal x 4) Execution exits the loop as soon as x = y Notice what this has bought us. Even though there are an infinite number of paths through program, we can prove that the program works by examining only a finite number of paths One of the great advantages that reasoning has over testing

Understanding loops by induction We just made an inductive argument Inducting over the number of iterations Computation induction Show that conjecture holds if zero iterations Show that it holds after n+1 iterations (assuming that it holds after n iterations) Two things to prove Some property is preserved (known as “partial correctness”) Loop invariant is preserved by each iteration The loop completes (known as “termination”) The “decrementing function” is reduced by each iteration

   Properties of Loop Invariant, LI // assert P while (b) S; // assert Q Find an invariant, LI, such that P  LI (true at start of first iteration) LI & b {S} LI (preserved by each iteration) (LI & b)  Q (implies the desired post-condition) It is sufficient to know that if loop terminates, Q will hold Finding the invariant is the key to reasoning about loops Inductive assertions is a complete method of proof: If a loop satisfies pre/post conditions, then there exists an invariant sufficient to prove it    Equivalently: P {while (b) S;} Q

Loop invariant for the example //assert x  0 & y = 0 while (x != y) { y = y + 1; } //assert x = y So, what is a suitable invariant? What makes the loop work? LI = x  y x  0 & y = 0  LI LI & x  y {y = y+1;} LI (LI & (x  y))  x = y

Total correctness via well-ordered sets We have not established that the loop terminates Suppose that the loop always reduces some variable’s value. Does the loop terminate if the variable is a Natural number? Integer? Non-negative real number? Boolean? ArrayList? The loop terminates if the variable values are (a subset of) a well-ordered set Ordered set Every non-empty subset has least element

Decrementing Function Decrementing function D(X) Maps state (program variables) to some well-ordered set This greatly simplifies reasoning about termination Consider: while (b) S; We seek D(X), where X is the state, such that An execution of the loop reduces the function’s value: LI & b {S} D(Xpost) < D(Xpre) If the function’s value is minimal, the loop terminates: (LI & D(X) = minVal)  b

Is “x-y” a good decrementing function? Proving Termination // assert x  0 & y = 0 // Loop invariant: x  y // Loop decrements: (x-y) while (x != y) { y = y + 1; } // assert x = y Is “x-y” a good decrementing function? Does the loop reduce the decrementing function’s value? // assert (y  x); let dpre = (x-y) y = y + 1; // assert (xpost – ypost) < dpre If the function has minimum value, does the loop exit? (x  y & x - y = 0)  (x = y) Where D: N  N, least value is 0 Decrementing function: x-y

Choosing loop invariants For straight-line code, the wp (weakest precondition) function gives us the appropriate property For loops, you have to guess: The loop invariant The decrementing function Then, use reasoning techniques to prove the goal property If the proof doesn't work: Maybe you chose a bad invariant or decrementing function Choose another and try again Maybe the loop is incorrect Fix the code Automatically choosing loop invariants is a research topic

I don’t routinely write Loop invariants and decrementing functions In Practice I don’t routinely write Loop invariants and decrementing functions I do write them when I am unsure about a loop When I have evidence that a loop is not working Add invariant and decrementing function if missing Write code to check them Understand why the code doesn't work Reason to ensure that no similar bugs remain All for today Next week, on to something quite different