Semantics and Verification of Software

Similar documents
Semantics and Verification of Software

Static Program Analysis

Static Program Analysis

Denotational Semantics

Denotational semantics

Static Program Analysis

Formal Techniques for Software Engineering: Denotational Semantics

COSE312: Compilers. Lecture 14 Semantic Analysis (4)

Denotational Semantics of Programs. : SimpleExp N.

CS422 - Programming Language Design

AAA616: Program Analysis. Lecture 3 Denotational Semantics

Semantics with Applications: Model-Based Program Analysis

G54FOP: Lecture 17 & 18 Denotational Semantics and Domain Theory III & IV

Static Program Analysis

Static Program Analysis

Hoare Logic: Part II

Dynamic Semantics. Dynamic Semantics. Operational Semantics Axiomatic Semantics Denotational Semantic. Operational Semantics

Denotational Semantics

Algebraic Reasoning for Probabilistic Action Systems and While-Loops

0.1 Random useful facts. 0.2 Language Definition

Software Engineering

Classical Program Logics: Hoare Logic, Weakest Liberal Preconditions

CMSC 631 Program Analysis and Understanding Fall Abstract Interpretation

Axiomatic Semantics. Lecture 9 CS 565 2/12/08

Theoretical Computer Science

Operational Semantics

Program verification. Hoare triples. Assertional semantics (cont) Example: Semantics of assignment. Assertional semantics of a program

CS 6110 Lecture 21 The Fixed-Point Theorem 8 March 2013 Lecturer: Andrew Myers. 1 Complete partial orders (CPOs) 2 Least fixed points of functions

Axiomatic Semantics: Verification Conditions. Review of Soundness and Completeness of Axiomatic Semantics. Announcements

CIS 500 Software Foundations. Midterm II. March 28, 2012

Probabilistic Model Checking and [Program] Analysis (CO469)

Formal Methods in Software Engineering

CIS 500: Software Foundations. November 8, Solutions

Lecture 2. Least Fixed Points

Hoare Logic and Model Checking

Axiomatic Semantics. Semantics of Programming Languages course. Joosep Rõõmusaare

Denotational semantics

Tutorial on Semantics Part I

Introduction to Kleene Algebras

CIS 500: Software Foundations

Modular Bisimulation Theory for Computations and Values

Principles of Program Analysis: Control Flow Analysis

SEMANTICS OF PROGRAMMING LANGUAGES Course Notes MC 308

CIS 500 Software Foundations. Final Exam. May 9, Answer key. Hoare Logic

Softwaretechnik. Lecture 13: Design by Contract. Peter Thiemann University of Freiburg, Germany

Origin in Mathematical Logic

Softwaretechnik. Lecture 13: Design by Contract. Peter Thiemann University of Freiburg, Germany

Denotational Semantics

Simply Typed Lambda-Calculi (II)

A Trajectory-based Strict Semantics for Program Slicing

Bi-inductive Structural Semantics

Program Analysis. Lecture 5. Rayna Dimitrova WS 2016/2017

On the Hardness of Analyzing Probabilistic Programs

Static Program Analysis

Program verification using Hoare Logic¹

CSE20: Discrete Mathematics

Introduction to Axiomatic Semantics

Recursion and Intro to Coq

Axiomatic Semantics. Hoare s Correctness Triplets Dijkstra s Predicate Transformers

Static Program Analysis using Abstract Interpretation

Program Analysis Part I : Sequential Programs

Roy L. Crole. Operational Semantics Abstract Machines and Correctness. University of Leicester, UK

A State-Space Based Approach to the Specification and Verification of Hybrid Systems and Its Axiomatic Basis

Spring 2016 Program Analysis and Verification. Lecture 3: Axiomatic Semantics I. Roman Manevich Ben-Gurion University

EDA045F: Program Analysis LECTURE 10: TYPES 1. Christoph Reichenbach

Dynamic Noninterference Analysis Using Context Sensitive Static Analyses. Gurvan Le Guernic July 14, 2007

Model Theory MARIA MANZANO. University of Salamanca, Spain. Translated by RUY J. G. B. DE QUEIROZ

Symbolic execution based on language transformation

C241 Homework Assignment 7

Basic Concepts of Abstract Interpretation

Precise Relational Invariants Through Strategy Iteration

Proving Inter-Program Properties

Design of Distributed Systems Melinda Tóth, Zoltán Horváth

A Logic for Information Flow Analysis with an Application to Forward Slicing of Simple Imperative Programs

The Formal Semantics of Programming Languages. Yuxin Deng Shanghai Jiao Tong University

Static Program Analysis

Chapter 2. Assertions. An Introduction to Separation Logic c 2011 John C. Reynolds February 3, 2011

A note on coinduction and weak bisimilarity for while programs

Operationally-Based Theories of Program Equivalence

Axiomatic Semantics. Stansifer Ch 2.4, Ch. 9 Winskel Ch.6 Slonneger and Kurtz Ch. 11 CSE

Overall organisation and objectives. Semantics and Validation. Example of validation. Principle of course/tp relationship

Reasoning About Imperative Programs. COS 441 Slides 10b

III.2 (b) Higher level programming concepts for URMs Anton Setzer

Axiomatic Semantics: Verification Conditions. Review of Soundness of Axiomatic Semantics. Questions? Announcements

Deductive Verification

Abstract Interpretation II

Imperative Insertion Sort

What does the partial order "mean"?

A Language-Independent Proof System for Full Program Equivalence

Probabilistic Programming

Spring 2015 Program Analysis and Verification. Lecture 4: Axiomatic Semantics I. Roman Manevich Ben-Gurion University

Soundness and Completeness of Axiomatic Semantics

A Trajectory-based Strict Semantics for Program Slicing

In this episode of The Verification Corner, Rustan Leino talks about Loop Invariants. He gives a brief summary of the theoretical foundations and

Program Verification Using Separation Logic

ESE601: Hybrid Systems. Introduction to verification

The WHILE Hierarchy of Program Schemes is Infinite

CSE 505, Fall 2005, Midterm Examination 8 November Please do not turn the page until everyone is ready.

Program verification. 18 October 2017

Hoare Calculus and Predicate Transformers

Transcription:

Semantics and Verification of Software Thomas Noll Software Modeling and Verification Group RWTH Aachen University http://moves.rwth-aachen.de/teaching/ss-15/sv-sw/

The Denotational Approach Denotational Semantics of WHILE Primary aspect of a program: its effect, i.e., input/output behavior In operational semantics: indirect definition of semantic functional by execution relation O. : Cmd (Σ Σ) Now: abstract from operational details Denotational semantics: direct definition of program effect by induction on its syntactic structure 3 of 24 Semantics and Verification of Software

Denotational Semantics of Expressions Semantics of Arithmetic Expressions Again: value of an expression determined by current state Definition 6.1 (Denotational semantics of arithmetic expressions) The (denotational) semantic functional for arithmetic expressions, A. : AExp (Σ Z), is given by: A z σ := z A x σ := σ(x) A a 1 +a 2 σ := A a 1 σ + A a 2 σ A a 1 -a 2 σ := A a 1 σ A a 2 σ A a 1 *a 2 σ := A a 1 σ A a 2 σ 5 of 24 Semantics and Verification of Software

Denotational Semantics of Expressions Semantics of Boolean Expressions Definition 6.2 (Denotational semantics of Boolean expressions) The (denotational) semantic functional for Boolean expressions is given by B. : BExp (Σ B) where B t σ := t{ true if A a1 σ = A a B a 1 =a 2 σ := 2 σ false otherwise { true if A a1 σ > A a B a 1 >a 2 σ := 2 σ false otherwise { true if B b σ = false B b σ := false otherwise { true if B b1 σ = B b B b 1 b 2 σ := 2 σ = true false otherwise { false if B b1 σ = B b B b 1 b 2 σ := 2 σ = false true otherwise 6 of 24 Semantics and Verification of Software

Denotational Semantics of Statements The Goal Now: semantic functional C. : Cmd (Σ Σ) Same type as operational functional O. : Cmd (Σ Σ) (in fact, both will turn out to be the same equivalence of operational and denotational semantics) 8 of 24 Semantics and Verification of Software

Denotational Semantics of Statements Auxiliary Functions Inductive definition of C. employs following auxiliary functions: identity on states: id Σ : Σ Σ : σ σ (strict) composition of partial state transformations: : (Σ Σ) (Σ Σ) (Σ Σ) where, for every f, g : Σ Σ and σ Σ, { g(f (σ)) if f (σ) defined (g f )(σ) := undefined otherwise semantic conditional: cond : (Σ B) (Σ Σ) (Σ Σ) (Σ Σ) where, for every p : Σ B, f, g : Σ Σ, and σ Σ, { f (σ) if p(σ) = true cond(p, f, g)(σ) := g(σ) otherwise 9 of 24 Semantics and Verification of Software

Denotational Semantics of Statements Semantics of Statements I Definition 6.3 (Denotational semantics of statements) The (denotational) semantic functional for statements, is given by: C. : Cmd (Σ Σ), C skip := id Σ C x := a σ := σ[x A a σ] C c 1 ;c 2 := C c 2 C c 1 C if b then c 1 else c 2 end := cond(b b, C c 1, C c 2 ) C while b do c end := fix(φ) where Φ : (Σ Σ) (Σ Σ) : f cond(b b, f C c, id Σ ) 10 of 24 Semantics and Verification of Software

Denotational Semantics of Statements Semantics of Statements II Remarks: Definition of C c given by induction on syntactic structure of c Cmd in particular, C while b do c end only refers to B b and C c (and not to C while b do c end again) note difference to O c : (wh-t) b, σ true c, σ σ while b do c, σ σ while b do c end, σ σ In C c 1 ;c 2 := C c 2 C c 1, function composition has to be strict since non-termination of c 1 implies non-termination of c 1 ;c 2 In C while b do c end := fix(φ), fix denotes a fixpoint operator (which remains to be defined) fixpoint semantics But: why fixpoints? 11 of 24 Semantics and Verification of Software

Denotational Semantics of Statements Why Fixpoints? Goal: preserve validity of equivalence C while b do c end ( ) = C if b then c;while b do c end else skip end (cf. Lemma 4.3) Using the known parts of Definition 6.3, we obtain: C while b do c end ( ) = C if b then c;while b do c end else skip end Def. 6.3 = cond(b b, C c;while b do c end, C skip ) Def. 6.3 = cond(b b, C while b do c end C c, id Σ ) Abbreviating f := C while b do c end this yields: f = cond(b b, f C c, id Σ ) Hence f must be a solution of this recursive equation In other words: f must be a fixpoint of the mapping Φ : (Σ Σ) (Σ Σ) : f cond(b b, f C c, id Σ ) (since the equation can be stated as f = Φ(f )) 12 of 24 Semantics and Verification of Software

Denotational Semantics of Statements Well-Definedness of Fixpoint Semantics But: fixpoint property not sufficient to obtain a well-defined semantics Potential problems: Existence: there does not need to exist any fixpoint. Examples: 1. φ 1 : N N : n n + 1 has no fixpoint { g1 if f = g 2. Φ 1 : (Σ Σ) (Σ Σ) : f 2 g 2 otherwise has no fixpoint if g 1 g 2 Solution: in our setting, fixpoints always exist Uniqueness: there might exist several fixpoints. Examples: 1. φ 2 : N N : n n 3 has fixpoints {0, 1} 2. every state transformation f is a fixpoint of Φ 2 : (Σ Σ) (Σ Σ) : f f Solution: uniqueness guaranteed by choosing a special fixpoint 13 of 24 Semantics and Verification of Software

Characterisation of fix(φ) Characterisation of fix(φ) Let b BExp and c Cmd Let Φ(f ) := cond(b b, f C c, id Σ ) Let f 0 : Σ Σ be a fixpoint of Φ, i.e., Φ(f 0 ) = f 0 Given some initial state σ 0 Σ, we will distinguish the following cases: 1. loop while b do c end terminates after n iterations (n N) 2. body c diverges in the n-th iteration (as it contains a non-terminating while statement) 3. loop while b do c end itself diverges 15 of 24 Semantics and Verification of Software

Characterisation of fix(φ) Case 1: Termination of Loop Loop while b do c end terminates after n iterations (n N) Formally: there exist σ 1,..., σ n Σ such that { true if 0 i < n B b σ i = and false if i = n C c σ i = σ i+1 for every 0 i < n Now the definition Φ(f ) := cond(b b, f C c, id Σ ) implies, for every 0 i < n, Φ(f 0 )(σ i ) = (f 0 C c )(σ i ) since B b σ i = true = f 0 (σ i+1 ) and Φ(f 0 )(σ n ) = σ n since B b σ n = false Since Φ(f 0 ) = f 0 it follows that { f0 (σ f 0 (σ i ) = i+1 ) if 0 i < n σ n if i = n and hence f 0 (σ 0 ) = f 0 (σ 1 ) =... f 0 (σ n ) = σ n All fixpoints f 0 coincide on σ 0 (with result σ n )! 16 of 24 Semantics and Verification of Software

Characterisation of fix(φ) Case 2: Divergence of Body Body c diverges in the n-th iteration (since it contains a non-terminating while statement) Formally: there exist σ 1,..., σ n 1 Σ such that B b σ i = true { σi+1 if 0 i n 2 C c σ i = undefined if i = n 1 for every 0 i < n and Just as in the previous case (setting σ n := undefined) it follows that f 0 (σ 0 ) = undefined Again all fixpoints f 0 coincide on σ 0 (with undefined result)! 17 of 24 Semantics and Verification of Software

Characterisation of fix(φ) Case 3: Divergence of Loop Loop while b do c end diverges Formally: there exist σ 1, σ 2,... Σ such that B b σ i = true C c σ i = σ i+1 and for every i N Here only derivable: f 0 (σ 0 ) = f 0 (σ i ) for every i N Value of f 0 (σ 0 ) not determined! 18 of 24 Semantics and Verification of Software

Characterisation of fix(φ) Summary For Φ(f 0 ) = f 0 and initial state σ 0 Σ, case distinction yields: 1. Loop while b do c end terminates after n iterations (n N) f 0 (σ 0 ) = σ n 2. Body c diverges in the n-th iteration f 0 (σ 0 ) = undefined 3. Loop while b do c end diverges no condition on f 0 (only f 0 (σ 0 ) = f 0 (σ i ) for every i N) Not surprising since, e.g., for the loop while true do skip end every f : Σ Σ is a fixpoint: Φ(f ) = cond(b true, f C skip, id Σ ) = f On the other hand, our operational understanding requires, for every σ 0 Σ, Conclusion fix(φ) is the least defined fixpoint of Φ. C while true do skip end σ 0 = undefined 19 of 24 Semantics and Verification of Software

Making It Precise Making It Precise I To use fixpoint theory, the notion of least defined has to be made precise. Given f, g : Σ Σ, let f g for every σ, σ Σ : f (σ) = σ g(σ) = σ (g is at least as defined as f ) Equivalent to requiring graph(f ) graph(g) where graph(h) := {(σ, σ ) σ Σ, σ = h(σ) defined} Σ Σ for every h : Σ Σ 21 of 24 Semantics and Verification of Software

Making It Precise Making It Precise II Example 6.4 Let x Var be fixed, and let f 0, f 1, f 2, f 3 : Σ Σ be given by f 0 (σ) := undefined { σ if σ(x) even f 1 (σ) := undefined otherwise { σ if σ(x) odd f 2 (σ) := f 3 (σ) := σ undefined otherwise This implies f 0 f 1 f 3, f 0 f 2 f 3, f 1 f 2, and f 2 f 1 22 of 24 Semantics and Verification of Software

Making It Precise Characterisation of fix(φ) I Now fix(φ) can be characterised by: fix(φ) is a fixpoint of Φ, i.e., Φ(fix(Φ)) = fix(φ) fix(φ) is minimal with respect to, i.e., for every f 0 : Σ Σ such that Φ(f 0 ) = f 0, fix(φ) f 0 Example 6.5 For while true do skip end we obtain for every f : Σ Σ: Φ(f) = cond(b true, f C skip, id Σ ) = f fix(φ) = f where f (σ) := undefined for every σ Σ (that is, graph(f ) = ) 23 of 24 Semantics and Verification of Software

Making It Precise Characterisation of fix(φ) II Goals: Prove existence of fix(φ) for Φ(f ) = cond(b b, f C c, id Σ ) Show how it can be computed (more exactly: approximated) Sufficient conditions: on domain Σ Σ: chain-complete partial order on function Φ: monotonicity and continuity 24 of 24 Semantics and Verification of Software