COMP 507: Computer-Aided Program Design

Similar documents
Hoare Logic: Proving Programs Correct

COMP 382: Reasoning about algorithms

Lecture Notes: Hoare Logic

Abstract Interpretation

Review: Hoare Logic Rules

Softwaretechnik. Program verification. Albert-Ludwigs-Universität Freiburg. June 28, Softwaretechnik June 28, / 24

An Annotated Language

Introduction to Axiomatic Semantics

CMSC 330: Organization of Programming Languages

Induction and Semantics in Dafny

Lectures 20, 21: Axiomatic Semantics

Formal Methods. CITS5501 Software Testing and Quality Assurance

Harvard School of Engineering and Applied Sciences CS 152: Programming Languages

Part II. Hoare Logic and Program Verification. Why specify programs? Specification and Verification. Code Verification. Why verify programs?

Overview. Verification with Functions and Pointers. IMP with assertions and assumptions. Proof rules for Assert and Assume. IMP+: IMP with functions

Lecture 10 Design by Contract

Lecture 5 - Axiomatic semantics

Softwaretechnik. Program verification. Software Engineering Albert-Ludwigs-University Freiburg. June 30, 2011

Reasoning About Imperative Programs. COS 441 Slides 10

Chapter 3. Describing Syntax and Semantics ISBN

Proving Programs Correct

Note that in this definition, n + m denotes the syntactic expression with three symbols n, +, and m, not to the number that is the sum of n and m.

Programming Languages Third Edition

A CRASH COURSE IN SEMANTICS

axiomatic semantics involving logical rules for deriving relations between preconditions and postconditions.

Semantics. There is no single widely acceptable notation or formalism for describing semantics Operational Semantics

! Use of formal notations. ! in software system descriptions. ! for a broad range of effects. ! and varying levels of use. !

AXIOMS OF AN IMPERATIVE LANGUAGE PARTIAL CORRECTNESS WEAK AND STRONG CONDITIONS. THE AXIOM FOR nop

Goals: Define the syntax of a simple imperative language Define a semantics using natural deduction 1

Hoare Logic. COMP2600 Formal Methods for Software Engineering. Rajeev Goré

CSE 307: Principles of Programming Languages

Backward Reasoning: Rule for Assignment. Backward Reasoning: Rule for Sequence. Simple Example. Hoare Logic, continued Reasoning About Loops

Shared Variables and Interference

CS2104 Prog. Lang. Concepts

CMSC 330: Organization of Programming Languages. Formal Semantics of a Prog. Lang. Specifying Syntax, Semantics

Verifying Java Programs Verifying Java Programs with KeY

3.7 Denotational Semantics

Shared Variables and Interference

Introduction to Axiomatic Semantics (1/2)

COSC252: Programming Languages: Semantic Specification. Jeremy Bolton, PhD Adjunct Professor

Programming Languages and Compilers Qualifying Examination. Answer 4 of 6 questions.

Programming Languages

Program Static Analysis. Overview

Syntax vs. semantics. Detour: Natural deduction. Syntax vs. semantics (cont d) Syntax = grammatical structure Semantics = underlying meaning

Outline. Introduction. 2 Proof of Correctness. 3 Final Notes. Precondition P 1 : Inputs include

Introduction to Axiomatic Semantics (1/2)

Pierce Ch. 3, 8, 11, 15. Type Systems

Formal Semantics of Programming Languages

Chapter 3. Describing Syntax and Semantics

Formal Syntax and Semantics of Programming Languages

Testing, Debugging, and Verification exam DIT082/TDA567. Day: 9 January 2016 Time: Will be published mid February or earlier

Verification Condition Generation

The Rule of Constancy(Derived Frame Rule)

1.3. Conditional expressions To express case distinctions like

Homework 3 COSE212, Fall 2018

Exercises: program verification using SAT/SMT

Basic Verification Strategy

Incremental Proof Development in Dafny

Handout 9: Imperative Programs and State

Specifying and Verifying Programs (Part 2)

Software Quality Assurance

Formal Semantics of Programming Languages

Variables. Substitution

Testing, Debugging, and Verification

Formal Systems II: Applications

Mutable References. Chapter 1

Program Verification. Program Verification 307/434

Data Structures and Algorithms. Part 2

The Formal Semantics of Programming Languages An Introduction. Glynn Winskel. The MIT Press Cambridge, Massachusetts London, England

CIS 500 Software Foundations. Final Exam. May 3, Answer key

Reasoning about programs

Last time. Reasoning about programs. Coming up. Project Final Presentations. This Thursday, Nov 30: 4 th in-class exercise

Functor abstract domain by example

The University of Nottingham SCHOOL OF COMPUTER SCIENCE A LEVEL 4 MODULE, SPRING SEMESTER MATHEMATICAL FOUNDATIONS OF PROGRAMMING ANSWERS

Program certification with computational

Verifying Java Programs Verifying Java Programs with KeY

Searching Algorithms/Time Analysis

Program Verification (Rosen, Sections 5.5)

Intro to semantics; Small-step semantics Lecture 1 Tuesday, January 29, 2013

02157 Functional Programming Interpreters for two simple languages including exercises

Programming Languages Fall 2014

Chapter 3 (part 3) Describing Syntax and Semantics

Semantics with Applications 3. More on Operational Semantics

6. Hoare Logic and Weakest Preconditions

Checking Program Properties with ESC/Java

Chapter 3. Describing Syntax and Semantics ISBN

Chapter 3. Describing Syntax and Semantics

The semantics of a programming language is concerned with the meaning of programs, that is, how programs behave when executed on computers.

Reminder of the last lecture. Aliasing Issues: Call by reference, Pointer programs. Introducing Aliasing Issues. Home Work from previous lecture

Guarded Commands, Nondeterminancy and Formal Derivation of Programs. Edsger W. Dijkstra. CACM 18, 8 pp (Aug. 1975).

Hardware versus software

CVO103: Programming Languages. Lecture 5 Design and Implementation of PLs (1) Expressions

The divide and conquer strategy has three basic parts. For a given problem of size n,

Proving Properties on Programs From the Coq Tutorial at ITP 2015

Exercise 3. Syntax Extensions. Reminder of the last lecture. This Lecture s Goals

Lecture 3 Notes Arrays

Axiomatic Semantics. Automated Deduction - George Necula - Lecture 2 1

Harvard School of Engineering and Applied Sciences CS 152: Programming Languages

4/24/18. Overview. Program Static Analysis. Has anyone done static analysis? What is static analysis? Why static analysis?

Forward Assignment; Strongest Postconditions

Transcription:

Fall 2014 April 7, 2015

Goal: Correctness proofs Prove that an algorithm written in an imperative language is correct

Induction for algorithmic correctness Induction for functional programs: The program computes the right outputs on the empty list Assuming the program computes the right outputs on a list L, it computes the right outputs on m :: L

Induction for algorithmic correctness Induction for functional programs: The program computes the right outputs on the empty list Assuming the program computes the right outputs on a list L, it computes the right outputs on m :: L Induction for imperative programs: All program executions of length 1 are correct If all executions of length k lead to correct outputs, then so do all executions of length (k + 1)

How do we know this program is correct? 1 method Find(a: array<int>, x: int) returns (j : int) 2 requires a!= null; 3 { 4 var m := 0; 5 var n := a.length; 6 while (m < n) 7 { 8 j := (m + n) / 2; 9 if (a[j] < x) { 10 m := j + 1; 11 } else if (x < a[j]) { 12 n := j; 13 } else { 14 return; 15 } 16 } 17 j := -1; 18 }

Correctness of programs Operational semantics defines how a program actually behaves Specifications state how a program should behave Goal: Guarantee that the program follows the specification

Structured programs Language syntax (can be augmented with other constructs): Assume a set of variables Var, a set of constants Const, a set of arithmetic operators Func, a set of relational operators Pred e ::= f(e 1, e 2 ) x n where x Var, n Const, f Func b ::= R(e 1, e 2 ) where R Pred S ::= x := e S 1 ; S 2 skip Example: 1 i := 0; 2 sum := 0; 3 while (i > n) { 4 i := i + 1; 5 sum := sum + i; 6 } if b then S 1 else S 2 while b do S 1

Operational semantics How are expressions/statements evaluated?

Operational semantics How are expressions/statements evaluated? Interpretation: Domain of values over which variables range (specifically, integers) Each constant a mapped to a value a Each arithmetic operator f mapped to a mathematical function that returns a value + mapped to the addition operation over integers Each relational operator R mapped to a mathematical predicate >= mapped to operator over integers

Operational semantics How are expressions/statements evaluated? Interpretation: Domain of values over which variables range (specifically, integers) Each constant a mapped to a value a Each arithmetic operator f mapped to a mathematical function that returns a value + mapped to the addition operation over integers Each relational operator R mapped to a mathematical predicate >= mapped to operator over integers State σ: function mapping variables to values

Semantic judgments What does an expression or statement do? e, σ n: Arithmetic expression e evaluates to value n at state σ b, σ bv: Boolean expression b evaluates to value bv at state σ S, σ σ : If you start executing S at state σ, then if the program terminates, then you end up at state σ

Defining semantics Semantics usually presented using inference rules: J 1... J k J (J holds assuming J 1 through J k hold)

Defining semantics (1) a, σ a x, σ σ(x) e 1, σ a 1 e 2, σ a 2 f(e 1, e 2 ), σ f (a 1, a 2 ) e 1, σ a 1 e 2, σ a 2 R(e 1, e 2 ), σ R(a 1, a 2 )

Defining semantics (2) skip, σ σ e, σ a x := e, σ σ[x a] S 1, σ σ S 2, σ σ S 1 ; S 2, σ σ b, σ true S 1, σ σ if b then S 1 else S 2, σ σ b, σ false S 2, σ σ if b then S 1 else S 2, σ σ b, σ false while b do S 1, σ σ b, σ true S 1 ; while b do S 1, σ σ while b do S 1, σ σ

Operational semantics: Notes Executions: Derivation trees for judgments Evaluation order: The rules can be applied any any order In (e 1 + e 2 ), we could evaluate e 1 first or e 2 first The final result is the same

Operational semantics: Notes Executions: Derivation trees for judgments Evaluation order: The rules can be applied any any order In (e 1 + e 2 ), we could evaluate e 1 first or e 2 first The final result is the same Termination: Is it possible that there s no σ such that P, σ σ?

Operational semantics: Notes Executions: Derivation trees for judgments Evaluation order: The rules can be applied any any order In (e 1 + e 2 ), we could evaluate e 1 first or e 2 first The final result is the same Termination: Is it possible that there s no σ such that P, σ σ? Correctness: Program guarantees a property Post under the assumption Pre if For all σ, σ such that σ satisfies Pre and P, σ σ, it is guaranteed that σ satisfies Post

Operational semantics: Notes Executions: Derivation trees for judgments Evaluation order: The rules can be applied any any order In (e 1 + e 2 ), we could evaluate e 1 first or e 2 first The final result is the same Termination: Is it possible that there s no σ such that P, σ σ? Correctness: Program guarantees a property Post under the assumption Pre if For all σ, σ such that σ satisfies Pre and P, σ σ, it is guaranteed that σ satisfies Post Complexity: Assign unit cost to each application of a rule

Structured programs Pros: Cons: Resembles modern high-level languages Allows for complex data types, can be extended with additional language features Easy to compose Not as simple as Turing machines

Proving correctness We will use an automated proof assistant to do proofs of programs You write the proof, the assistant checks it for you The ultimate TA; doesn t allow you to cheat Dafny http://rise4fun.com/dafny

State predicates A (state) predicate is a boolean function on the program state. x = 8 x < y m n ( j : 0 j < a.length a[j] NaN) true false Intuitively, a property that holds at a point in a program execution.

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

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

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}

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}

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 do we have {P}S{Q R}?

Precise triples If {P}S{Q} and {P}S{R}, then do we have Yes. {P}S{Q R}? The most precise Q such that {P}S{Q} is called the strongest postcondition of S with respect to P.

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 Here s the crucial relationship between Hoare triples and weakest preconditions: {P}S{Q} if and only if P wp(s, Q)

Proving programs correct Consider programs of different shapes; for each shape, give method for systematic correctness proof e ::= f(e 1, e 2 ) x n where x Var, n Const, f Func b ::= R(e 1, e 2 ) where R Pred S ::= x := e S 1 ; S 2 skip if b S 1 else S 2 while b S 1

Proving programs correct: skip wp(skip, R) R Example: wp(skip, x n + y n = z n ) x n + y n = z n To prove {P}skip{Q}, show that P Q

Proving programs correct: assignments wp(w := E, R) R[w E] where R[w E] is obtained by starting with R and replacing w by 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 To prove {P}w := E{Q}, show that P Q[w E]

Dafny example 1 method foo(x: int) returns (y: int) 2 requires x > 0; 3 ensures y > 1; 4 { 5 y := x + 1; 6 } http://rise4fun.com/dafny http://research.microsoft.com/en-us/um/people/leino/ papers/krml220.pdf

Sequential composition wp(s; T, R) wp(s, wp(t, R)) Example: Compute the value of wp(y := y + 1; x := x + 3 y, y 10 3 x)

Branching wp(if B then S else T, R) (B wp(s, R)) ( B wp(t, R))

Branching wp(if B then S else T, R) (B wp(s, R)) ( B wp(t, R)) (B wp(s, R) is the set of states that pass the test if B and lead to R when pushed through S ( B wp(s, R) is the set of states that fail the test if B and lead to R when pushed through T Example: Compute the value of wp(if x < y then z := y else z := x, 0 z) wp(if x 10 then x := x + 1 else x := x + 2, x 10)

Example What s the condition under which this program will use pointers safely? 1 if (x!= null) { 2 n := x.f; 3 } 4 else { 5 n := z-1; 6 z := z + 1; 7 } 8 a = new char[n];

Proving programs correct: Loops To prove {P}while B S{Q} find invariant J and a ranking function rf such that: invariant holds initially: P J invariant is maintained: {J B}S{J} invariant is sufficient: J B Q ranking function is bounded: J B 0 rf ranking function decreases: {J B rf = RF }S{rf < RF }

Example: Array sum 1 {N 0}; 2 k := 0; 3 s := 0; 4 while (k!= N) { 5 s := s + a[k]; 6 k := k + 1 7 } 8 {s = 0 i<n a[i]}

Example: Array sum 1 {N 0} 2 k := 0; 3 s := 0; 4 {J} 5 while (k!= N) { 6 s := s + a[k]; 7 k := k + 1 8 {J rf < RF } 9 } 10 {J (k N)} 11 {s = 0 i<n a[i]}

Example: Array sum 1 {N 0} 2 k := 0; 3 s := 0; 4 {J} 5 while (k!= N) { 6 s := s + a[k]; 7 k := k + 1 8 {J rf < RF } 9 } 10 {J (k N)} 11 {s = 0 i<n a[i]} J : vf : s = 0 i<k a[i] 0 k N N k

Exercise: Computing cubes 1 method Cube(N: int) returns (c: int) 2 requires 0 <= N; 3 ensures c == N*N*N; 4 { 5 c := 0; 6 var n := 0; 7 var k := 1; 8 var m := 6; 9 while (n < N) { 10 c := c + k; 11 k := k + m; 12 m := m + 6; 13 n := n + 1; 14 } 15 }

Exercise: Computing cubes 1 method Cube(N: int) returns (c: int) 2 requires 0 <= N; 3 ensures c == N*N*N; 4 { 5 c := 0; 6 var n := 0; var k := 1; var m := 6; 7 while (n < N) 8 invariant n <= N; 9 invariant c == n*n*n; 10 invariant k == 3*n*n + 3*n + 1; 11 invariant m == 6*n + 6; 12 decreases (N - n); 13 { 14 c := c + k; 15 k := k + m; 16 m := m + 6; 17 n := n + 1; 18 } 19 }

Question: Does this program terminate? 1 method Foo(x: int, y: int, z : int) { 2 var x := x; 3 var y := y; 4 while (x > 0 && y > 0) 5 { 6 if (z == 1) { 7 x := x - 1; 8 y := y + 1; 9 } 10 else { 11 y := y - 1; 12 } 13 } 14 }

Proving programs correct: Procedures Suppose you have a program 1 method M( ){ 2... 3 P( ); 4... 5 } Proof goals: At the point when control enters P from within M, the ranking function of P must have a lower value than the ranking function of M Assuming a Hoare triple for P, guarantee a Hoare triple for M.

Proving programs correct: Procedures 1 method Ackermann(m: int, n: int) returns (r: int) 2 decreases m, n; 3 requires m >= 0 && n >= 0; 4 ensures r > 0; 5 { 6 if (m <= 0) { 7 r := n + 1; 8 } 9 else if (n <= 0) { 10 r := Ackermann(m - 1, 1); 11 } 12 else { 13 var z; 14 z := Ackermann(m, n - 1); 15 r := Ackermann(m - 1, z); 16 } 17 }

Procedures Dafny also permits a functional notation: 1 function Ackermann(m: int, n: int): int 2 decreases m, n; 3 requires m >= 0 && n >= 0; 4 ensures Ackermann(m,n) > 0; 5 { 6 if m <= 0 then 7 n + 1 8 else if n <= 0 then 9 Ackermann(m - 1, 1) 10 else 11 Ackermann(m - 1, Ackermann(m, n - 1)) 12 }

Proving Fibonacci Can you show that Compute_Fib is correct? 1 function Fib(n: nat): nat 2 { 3 if n < 2 then n else Fib(n - 1) + Fib(n-2) 4 } 5 6 method Compute_Fib(n: nat) returns (x: nat) 7 ensures x == Fib(n); 8 { 9 var i := 0; 10 x := 0; 11 var y := 1; 12 while (i < n) { 13 x, y := y, x + y; 14 i := i + 1; 15 } 16 }