2em Deductive Verification of Programs · Computer Systems and Correctness I Suppose we design a...

Deductive Verification of Programs

Laura Kovacs

TU Wien

1 / 141

Outline

Introduction

Small Imperative Language IMP

2 / 141

Computer Systems and Correctness

I Suppose we design a (complex) software system.

I We have requirements on how the system should function, forexample safety, security, availability, etc.

I How can one ensure that the system satisfies theserequirements?

Deductive verification of programs

3 / 141






4 / 141






5 / 141






6 / 141

A Small ExampleConsider the following program:

/* Returns a new array of integers of a givenlength initialised by a non-zero value */

int* allocateArray(int length){int i;int* array;array = malloc(sizeof(int)*length);

for (i = 0;i <= length;i++)array[i] = 0;

return array;}

Is this program correct?

7 / 141





return array;}


8 / 141





return array;}

Is this program correct?Hardly: it writes into memory that has not been allocated.

9 / 141




for (i = 0;i < length;i++)array[i] = 0;

return array;}


10 / 141



int* allocateArray(int length){int i;int* array;array = malloc(sizeof(int)*length); // may return 0!

for (i = 0;i < length;i++)array[i] = 0;

return array;}

Is this program correct?No: it may write to the null address.

11 / 141



int* allocateArray(int length){int i;int* array;array = malloc(sizeof(int)*length);if (!array) return 0;for (i = 0;i < length;i++)

array[i] = 0;return array;

}


12 / 141





}

Is this program correct?No: it initialises the array by zeros

13 / 141





}


We discussed correctness of a program without defining what itmeans.

14 / 141





}


We discussed correctness of a program without defining what itmeans.So what is correctness?

15 / 141

Notes

I We could spot the first two errors without knowing anything aboutthe intended meaning of the program. But we had to understandthe meaning of the program in general and some specificproperties of programming in C-like languages (or otherprogramming languages).

I To understand the last “error” we had to know something aboutthe intended behaviour of the program.

16 / 141

Notes

I We could spot the first two errors without knowing anything aboutthe intended meaning of the program. But we had to understandthe meaning of the program in general and some specificproperties of programming in C-like languages (or otherprogramming languages).

I To understand the last “error” we had to know something aboutthe intended behaviour of the program.

17 / 141

How to establish correctness

I Consider the program/system as amathematical object.Build a formal model of the system.

I Find a formal language forexpressing intended properties.

I Prove that the system modelsatisfies the specification.

State Transition Systemsand its Semantics

First-Order Logic (FOL),

SAT/SMT/FOL Formulas,

Deductive verification,

18 / 141









19 / 141









20 / 141




This language must have asemantics that explains what arepossible interpretations of thesentences of the formal language.

The semantics is normally based onnotions is true, is false, satisfies.






21 / 141




This language must have asemantics that explains what arepossible interpretations of thesentences of the formal language.

The semantics is normally based onnotions is true, is false, satisfies.



First-Order Logic (FOL),Temporal Logic



22 / 141




I Write a specification, that is,intended properties of the system inthis language.






23 / 141








SAT/SMT/FOL Formulas,Temporal Logic Formulas


24 / 141










25 / 141









Deductive verification,model checking

26 / 141










27 / 141


Program

Specification

Deductiveverifier

Correct

Incorrect

I Statically reason about program behavior without executing theprogram: consider all possible program executions under all inputs

I Examples of specifications: absence of arithmetic overflow, arrayis sorted, program terminates . . .

28 / 141


Program

Specification

Deductiveverifier

Correct

Incorrect

I Statically reason about program behavior without executing theprogram: consider all possible program executions under all inputs

I Examples of specifications: absence of arithmetic overflow, arrayis sorted, program terminates . . .

29 / 141


Program

Terminates

Specification

Deductiveverifier

Correct

Incorrect

30 / 141


Program

Terminates

Specification

Deductiveverifier

Correct

Incorrect

The Halting Problem

: UndecidableI A problem is undecidable if there does not exist a

that can solve itAlan Turing, 1936

31 / 141


Program

Terminates

Specification

Deductiveverifier

Correct

Incorrect

The Halting Problem: UndecidableI A problem is undecidable if there does not exist a

Turing machine that can solve itAlan Turing, 1936

32 / 141


Program

Terminates

Specification

Deductiveverifier

Correct

Incorrect


C/Java program that can solve itAlan Turing, 1936

33 / 141


Program

Terminates

Specification

Deductiveverifier

Correct

Incorrect


computer program that can solve itAlan Turing, 1936

34 / 141


Program

Terminates

Specification

Deductiveverifier

Correct

Incorrect

Undecidable: Verifier cannot exist

I There is no computer program that can alwaysdecide whether a computer program satisfies anon-trivial specification (Rice Theorem)

Alan Turing, 1936

35 / 141


Program

Terminates

Specification

Deductiveverifier

Correct

Incorrect

Undecidable: Verifier cannot existI There is no computer program that can always

decide whether a computer program satisfies anon-trivial specification (Rice Theorem)

Alan Turing, 1936

36 / 141

Deductive Verification – Living with Undecidability

I Programs that “sometimes” diverge

I Limit programs that can be analyzedI finite-state, loop-free, bounded arithmetic, . . .

I Partial/unsound verification approachesI Testing: analyze program executions on a fixed input set

37 / 141





38 / 141





39 / 141





if (x-100<=0)if (y-100<=0)if (x+y-200==0)

crash();

If x and y are 32-bit integers, whatis the probability of a crash?

I 1/264

Testing is hard!

40 / 141





if (x-100<=0)if (y-100<=0)if (x+y-200==0)

crash();

If x and y are 32-bit integers, whatis the probability of a crash?

I 1/264

Testing is hard!

41 / 141





if (x-100<=0)if (y-100<=0)if (x+y-200==0)

crash();

If x and y are 32-bit integers, whatis the probability of a crash?I 1/264

Testing is hard!

42 / 141





if (x-100<=0)if (y-100<=0)if (x+y-200==0)

crash();

If x and y are 32-bit integers, whatis the probability of a crash?I 1/264

Testing is hard!

43 / 141





I AbstractionsI Model checking: verify a superset of program executions

I User assistanceI Deductive verification: using program annotations (e.g. loop invariants)

Algorithmic approach to deductive verification: (my research area)

I automate the generation of annotations,I fully automatic, push-button verification for classes of programs

44 / 141









45 / 141









46 / 141


Program

Specification

Deductiveverifier

Theoremprover

VC:

SAT/SMT/ FOL

Formula

Correct(Valid)

Incorrect(Unsat)

VC

VC

I Verification condition (VC): φ s.t. the program is correct iff φ isvalid

I Available tools: Dafny (Microsoft), Why3, KeY, ESC/Java, . . .

47 / 141

Deductive Verification of Programs in Practice

Program

Specification

Deductiveverifier

Theoremprover

VC:

SAT/SMT/ FOL

Formula

Correct(Valid)

Incorrect(Unsat)

VC

VC

I Verification condition (VC): A logical formula φ s.t. the program iscorrect iff φ is valid


48 / 141

Deductive Verification of Programs in Practice

Program

Specification

Deductiveverifier

Theoremprover

VC:

SAT/SMT/ FOL

Formula

Correct(Valid)

Incorrect(Unsat)

I Verification condition (VC): SAT/SMT/FOL formula φ s.t. theprogram is correct iff φ is valid


49 / 141

Deductive Verification of Programs in Dafny

Revisiting our allocateArray example

50 / 141


method allocateArray(a:array<int>, length:int)

requires 0<=length<a.Lengthmodifies aensures forall k::0<=k<length==>a[k]!=0

{var i:int;i:=0;while (i<length)

invariant (forall k::0<=k<i&& k<length==>a[k]!=0);

{a[i]:=1; i:=i+1;

}}

51 / 141


method allocateArray(a:array<int>, length:int)requires 0<=length<a.Lengthmodifies a

ensures forall k::0<=k<length==>a[k]!=0

{var i:int;i:=0;while (i<length)


{a[i]:=1; i:=i+1;

}}

52 / 141


method allocateArray(a:array<int>, length:int)requires 0<=length<a.Lengthmodifies aensures forall k::0<=k<length==>a[k]!=0{var i:int;i:=0;while (i<length)


{a[i]:=1; i:=i+1;

}}

53 / 141


method allocateArray(a:array<int>, length:int)requires 0<=length<a.Lengthmodifies aensures forall k::0<=k<length==>a[k]!=0{var i:int;i:=0;while (i<length)invariant (forall k::0<=k<i&& k<length==>a[k]!=0);

{a[i]:=1; i:=i+1;

}}

54 / 141


I Living with undecidability;

I Algorithmic approach, using Hoare logic;

I Automated approach, thanks to SAT/SMT solving and theoremproving.

55 / 141


Tentative list of topics to be addressed:I Small imperative language IMP

I Syntax and semantics

I Hoare logic: basis of all deductive verification techniques

I Deductive verification of IMP

I Axiomatic Semantics

I Predicate transformers - for algorithmic verification

I Inferring loop invariants automatically

56 / 141

Outline

Introduction

Small Imperative Language IMP

57 / 141

Small Imperative Language IMP – Syntax

We consider a small imperative language IMP.

Syntactic Sets of IMP

• Int positive and negative (integer) numerals n,m, . . . (e.g. −5, 0, 10)

• Loc locations x , y , z, . . .• AExp arithmetic expressions a• BExp boolean expressions b• P programs p

58 / 141


Abstract Syntax of IMP: Arithmetic Expressions AExp

a ::= n for n ∈ Int

| x for x ∈ Loc

| a1 + a2 for a1,a2 ∈ AExp

| a1 − a2 for a1,a2 ∈ AExp

| a1 ∗ a2 for a1,a2 ∈ AExp

| a1/a2 for a1,a2 ∈ AExp

I In the abstract synthax, we omit parantheses.

2 + 3 ∗ 4− 5

can be parsed as 2 + ((3 ∗ 4)− 5 or as (2 + 3) ∗ (4− 5), depending onthe concrete syntax (e.g. using operator precedence).

I 3 + 5 is not syntactically identical to 5 + 3.But, (3 + 5) is syntactically identical to 3 + 5.

59 / 141




| x for x ∈ Loc






2 + 3 ∗ 4− 5



60 / 141




| x for x ∈ Loc






2 + 3 ∗ 4− 5



61 / 141


Abstract Syntax of IMP: Boolean Expressions BExp

b ::= true

| false

| a1 AOP a2 for a1,a2 ∈ AExp and AOP ∈ {=, <,>,≤,≥}| ¬b for b ∈ BExp

| b1 BOP b2 for b1,b2 ∈ BExp and BOP ∈ {∧,∨}

62 / 141


Abstract Syntax of IMP: Programs P

p ::= skip

| abort

| x := a for x ∈ Loc and a ∈ AExp

| p1; p2 for p1,p2 ∈ P

| if b then p1 else p2 for b ∈ BExp and p1,p2 ∈ P

| while b do p od for b ∈ BExp and p ∈ P

63 / 141


Example of an IMP Program

p

=⇒ p1; p2

=⇒ p1; p3; p4

=⇒∗ x := e1; y := e2; while b do p5 od

=⇒∗ x := 10; y := 0; while a1 > a2 do p6; p7 od

=⇒∗ x := 10; y := 0; while x > 0 do y := y + x ; x := x − 1 od

64 / 141



p =⇒ p1; p2

=⇒ p1; p3; p4




65 / 141



p =⇒ p1; p2

=⇒ p1; p3; p4




66 / 141



p =⇒ p1; p2

=⇒ p1; p3; p4




67 / 141

Small Imperative Language IMP – Semantics

I Meaning of IMP programs and expressions depends on thevalues of variables in locations.

I A state σ is a function from Loc to Int.

I σ(x) is the value/content of locations x in state σ

I the set of states Σ = {σ|σ : Loc→ Int}

68 / 141






69 / 141






70 / 141

Programs as State TransformersInput States Output States

Program

Program

Program

I Several inputs may be mapped to the same output.I Some inputs are not mapped to any output.

(Program aborts or loops.)I Some outputs are not reached from any input.I One input may be mapped to several outputs (non-determinism).

71 / 141


Program

Program

Program

I Several inputs may be mapped to the same output.

I Some inputs are not mapped to any output.(Program aborts or loops.)

I Some outputs are not reached from any input.I One input may be mapped to several outputs (non-determinism).

72 / 141


Program

Program

Program


(Program aborts or loops.)

I Some outputs are not reached from any input.I One input may be mapped to several outputs (non-determinism).

73 / 141


Program

Program

Program


(Program aborts or loops.)I Some outputs are not reached from any input.

I One input may be mapped to several outputs (non-determinism).

74 / 141


Program

Program

Program


(Program aborts or loops.)I Some outputs are not reached from any input.I One input may be mapped to several outputs (non-determinism).

75 / 141


I Evaluation of IMP expressions:

I Ternary relation on an AExp/BExp expression, a state σ and avalue v

I Denoted as 〈exp, σ〉 → v , where exp ∈ AExp or exp ∈ BExp:

“Expression exp in state σ evaluates to value v ”.

Operational semantics: “mapping of expressions to values”

76 / 141

Small Imperative Language IMP – Operational Semantics






I Why no state on the right of→?

Evaluation of IMP expressions has no side-effects (the state remainsunchanged)

I Can evaluations of expressions be considered as a function of 2arguments exp and σ?

Only if there is a unique value v for 〈exp, σ〉 → v

77 / 141











78 / 141











79 / 141











80 / 141







I The pair 〈exp, σ〉 is:I an arithmetic expression configuration, for exp ∈ AExp;I a boolean expression configuration, for exp ∈ BExp;

81 / 141


I Evaluation of IMP programs:

I Ternary relation on a program p, a state σ and a new state σ′

I Denoted as 〈p, σ〉 → σ′:

“Executing program p from state σ terminates in final state σ′”.

82 / 141






I Execution of a program has effectI but no direct value

I “result” of a program is a new state σ′

I Evaluation of a program:I may terminate in a final state

I may diverge and never yield a final state

83 / 141






I Execution of a program has effectI but no direct value

I “result” of a program is a new state σ′

I Evaluation of a program:I may terminate in a final state

I may diverge and never yield a final state

84 / 141






I Can evaluations of programs be considered as a function of 2arguments p and σ?

Only if there is a unique successor state

85 / 141






I Can evaluations of programs be considered as a function of 2arguments p and σ?

Only if there is a unique successor state

86 / 141






I The pair 〈p, σ〉 is a program configuration from which it remainsto execute p from state σ.

I A final state is also a program configuration, called finalconfiguration.

I Set of program configurations C = (P × Σ) ∪ Σ

I Transition relation ==> of IMP programs is a relation over C × CI 〈p, σ〉 ==> 〈p′, σ′〉 intermediate step of program executionI 〈p, σ〉 ==> σ′ last step of program execution

87 / 141








I Set of program configurations C = (P × Σ) ∪ Σ

I Transition relation ==> of IMP programs is a relation over C × CI 〈p, σ〉 ==> 〈p′, σ′〉 intermediate step of program executionI 〈p, σ〉 ==> σ′ last step of program execution

88 / 141








I Set of program configurations C = (P × Σ) ∪ ΣI Transition relation ==> of IMP programs is a relation over C × C

I 〈p, σ〉 ==> 〈p′, σ′〉 intermediate step of program executionI 〈p, σ〉 ==> σ′ last step of program execution

89 / 141


Evaluation Rule Notation:

F1 . . . Fk

G,

to denote “if F1, . . . ,Fk , then G”.

When k = 0, then G is an axiom:

G.

90 / 141


Note: In 〈a, σ〉 → v , the value v is an integer value.

Evaluation Rules for AExp

〈n, σ〉 → n, where n ∈ Z represents the integer number corresponding to n ∈ Int

〈x , σ〉 → σ(x)

〈a1, σ〉 → n1 〈a2, σ〉 → n2

〈a1 + a2, σ〉 → n1 +Z n2, where +Z is the integer sum operator

〈a1, σ〉 → n1 〈a2, σ〉 → n2

〈a1 − a2, σ〉 → n1 −Z n2, where−Z is the integer substraction operator

〈a1, σ〉 → n1 〈a2, σ〉 → n2

〈a1 ∗ a2, σ〉 → n1 ∗Z n2, where ∗Z is the integer product operator

〈a1, σ〉 → n1 〈a2, σ〉 → n2

〈a1/a2, σ〉 → n1/Z n2, where /Z is the of integer division operator

91 / 141





〈x , σ〉 → σ(x)

〈a1, σ〉 → n1 〈a2, σ〉 → n2


〈a1, σ〉 → n1 〈a2, σ〉 → n2


〈a1, σ〉 → n1 〈a2, σ〉 → n2


〈a1, σ〉 → n1 〈a2, σ〉 → n2


92 / 141





〈x , σ〉 → σ(x)

〈a1, σ〉 → n1 〈a2, σ〉 → n2


〈a1, σ〉 → n1 〈a2, σ〉 → n2


〈a1, σ〉 → n1 〈a2, σ〉 → n2


〈a1, σ〉 → n1 〈a2, σ〉 → n2


93 / 141





〈x , σ〉 → σ(x)

〈a1, σ〉 → n1 〈a2, σ〉 → n2


〈a1, σ〉 → n1 〈a2, σ〉 → n2


〈a1, σ〉 → n1 〈a2, σ〉 → n2


〈a1, σ〉 → n1 〈a2, σ〉 → n2


94 / 141





〈x , σ〉 → σ(x)

〈a1, σ〉 → n1 〈a2, σ〉 → n2


〈a1, σ〉 → n1 〈a2, σ〉 → n2


〈a1, σ〉 → n1 〈a2, σ〉 → n2


〈a1, σ〉 → n1 〈a2, σ〉 → n2


95 / 141


An Example of Evaluating a ∈ AExp

Let a be (x + 5) + (8 + 10).Consider the state σ0 with σ0(x) = 0.

〈x , σ0〉 →

0locations

〈5, σ0〉 →

5numbers

〈x + 5, σ0〉 →

5sum

〈8, σ0〉 → 8

numbers

〈10, σ0〉 → 10

numbers

〈8 + 10, σ0〉 →

18sum

〈(x + 5) + (8 + 10), σ0〉 →

23sum

The above structure of evaluation rules illustrates the derivation tree, orsimply derivation of 〈a, σ0〉 → 23.

96 / 141




〈x , σ0〉 →

0locations

〈5, σ0〉 →

5numbers

〈x + 5, σ0〉 →

5sum

〈8, σ0〉 → 8

numbers

〈10, σ0〉 → 10

numbers

〈8 + 10, σ0〉 →

18sum

〈(x + 5) + (8 + 10), σ0〉 →

23

sum


97 / 141




〈x , σ0〉 →

0locations

〈5, σ0〉 →

5numbers

〈x + 5, σ0〉 →

5

sum

〈8, σ0〉 → 8

numbers

〈10, σ0〉 → 10

numbers

〈8 + 10, σ0〉 →

18sum

〈(x + 5) + (8 + 10), σ0〉 →

23

sum


98 / 141




〈x , σ0〉 → 0locations

〈5, σ0〉 → 5numbers

〈x + 5, σ0〉 → 5sum

〈8, σ0〉 → 8

numbers

〈10, σ0〉 → 10

numbers

〈8 + 10, σ0〉 →

18sum

〈(x + 5) + (8 + 10), σ0〉 →

23

sum


99 / 141






〈x + 5, σ0〉 → 5sum



〈8 + 10, σ0〉 → 18sum

〈(x + 5) + (8 + 10), σ0〉 →

23

sum


100 / 141






〈x + 5, σ0〉 → 5sum



〈8 + 10, σ0〉 → 18sum

〈(x + 5) + (8 + 10), σ0〉 → 23sum


101 / 141






〈x + 5, σ0〉 → 5sum



〈8 + 10, σ0〉 → 18sum

〈(x + 5) + (8 + 10), σ0〉 → 23sum


102 / 141


Note: In 〈b, σ〉 → v , the value v is a boolean value/truth value.

103 / 141


Evaluation Rules for BExp

〈true, σ〉 → true, where true represents the boolean value 1 (true)

〈false, σ〉 → false, where false represents the boolean value 0 (false)

〈a1, σ〉 → n1 〈a2, σ〉 → n2

〈a1 = a2, σ〉 → true, if n1 and n2 are equal

〈a1, σ〉 → n1 〈a2, σ〉 → n2

〈a1 = a2, σ〉 → false, if n1 and n2 are not equal

〈a1, σ〉 → n1 〈a2, σ〉 → n2

〈a1 ≤ a2, σ〉 → true, if n1 is less than or equal to n2

〈a1, σ〉 → n1 〈a2, σ〉 → n2

〈a1 ≤ a2, σ〉 → false, if n1 is not less than or equal to n2

104 / 141





〈a1, σ〉 → n1 〈a2, σ〉 → n2


〈a1, σ〉 → n1 〈a2, σ〉 → n2


〈a1, σ〉 → n1 〈a2, σ〉 → n2


〈a1, σ〉 → n1 〈a2, σ〉 → n2


105 / 141





〈a1, σ〉 → n1 〈a2, σ〉 → n2


〈a1, σ〉 → n1 〈a2, σ〉 → n2


〈a1, σ〉 → n1 〈a2, σ〉 → n2


〈a1, σ〉 → n1 〈a2, σ〉 → n2


106 / 141


Evaluation Rules for BExp (contd)

〈a1, σ〉 → n1 〈a2, σ〉 → n2

〈a1 ≥ a2, σ〉 → true, if n1 is greater than or equal to n2

〈a1, σ〉 → n1 〈a2, σ〉 → n2

〈a1 ≥ a2, σ〉 → false, if n1 is not greater than or equal to n2

〈a1, σ〉 → n1 〈a2, σ〉 → n2

〈a1 < a2, σ〉 → true, if n1 is less than n2

〈a1, σ〉 → n1 〈a2, σ〉 → n2

〈a1 < a2, σ〉 → false, if n1 is not less than n2

〈a1, σ〉 → n1 〈a2, σ〉 → n2

〈a1 > a2, σ〉 → true, if n1 is greater than n2

〈a1, σ〉 → n1 〈a2, σ〉 → n2

〈a1 > a2, σ〉 → false, if n1 is not greater than n2

107 / 141



〈b, σ〉 → true〈¬b, σ〉 → false

neg〈b, σ〉 → false〈¬b, σ〉 → true

neg

〈b1, σ〉 → t1 〈b2, σ〉 → t2〈b1 ∧ b2, σ〉 → t

, where t is true if both t1 and t2are true, and is false otherwise.

〈b1, σ〉 → t1 〈b2, σ〉 → t2〈b1 ∨ b2, σ〉 → t

, where t is false if both t1 and t2are false, and is true otherwise.

108 / 141





neg

〈b1, σ〉 → t1 〈b2, σ〉 → t2〈b1 ∧ b2, σ〉 → t


〈b1, σ〉 → t1 〈b2, σ〉 → t2〈b1 ∨ b2, σ〉 → t


109 / 141





neg

〈b1, σ〉 → t1 〈b2, σ〉 → t2〈b1 ∧ b2, σ〉 → t


〈b1, σ〉 → t1 〈b2, σ〉 → t2〈b1 ∨ b2, σ〉 → t


110 / 141


Evaluation Rules for P

〈skip, σ〉 →

σ

〈abort, σ〉 →

undefined

〈a, σ〉 → v

〈x := a, σ〉 →

σ[x/v ]

Notation: We write σ[x/v ] to denote the state obtained from σ by replacing xby v . That is:

σ[x/v ](y) =

{v , if y = x ,σ(y), otherwise

111 / 141



〈skip, σ〉 → σ 〈abort, σ〉 6→ undefined

Evaluation of IMP programs is a partial relation!

〈a, σ〉 → v

〈x := a, σ〉 →

σ[x/v ]


σ[x/v ](y) =


112 / 141




〈a, σ〉 → v

〈x := a, σ〉 →

σ[x/v ]


σ[x/v ](y) =


113 / 141




〈a, σ〉 → v〈x := a, σ〉 → σ[x/v ]


σ[x/v ](y) =


114 / 141




〈a, σ〉 → v〈x := a, σ〉 → σ[x/v ]

〈p1, σ〉 → σ′ 〈p2, σ′〉 → σ′′

〈p1; p2, σ〉 →

σ′′

〈b, σ〉 → true 〈p1, σ〉 → σ′

〈if b then p1 else p2, σ〉 →

σ′〈b, σ〉 → false 〈p2, σ〉 → σ′

〈if b then p1 else p2, σ〉 → σ′

〈b, σ〉 → false

〈while b do p od , σ〉 →

σ

〈b, σ〉 → true 〈p, σ〉 → σ′ 〈while b do p od , σ′〉 → σ′′


σ′′

115 / 141




〈a, σ〉 → v〈x := a, σ〉 → σ[x/v ]

〈p1, σ〉 → σ′ 〈p2, σ′〉 → σ′′

〈p1; p2, σ〉 → σ′′

〈b, σ〉 → true 〈p1, σ〉 → σ′


σ′〈b, σ〉 → false 〈p2, σ〉 → σ′




σ



σ′′

116 / 141




〈a, σ〉 → v〈x := a, σ〉 → σ[x/v ]

〈p1, σ〉 → σ′ 〈p2, σ′〉 → σ′′

〈p1; p2, σ〉 →

σ′′

〈b, σ〉 → true 〈p1, σ〉 → σ′


σ′〈b, σ〉 → false 〈p2, σ〉 → σ′




σ



σ′′

117 / 141




〈a, σ〉 → v〈x := a, σ〉 → σ[x/v ]

〈p1, σ〉 → σ′ 〈p2, σ′〉 → σ′′

〈p1; p2, σ〉 →

σ′′

〈b, σ〉 → true 〈p1, σ〉 → σ′


〈b, σ〉 → false 〈p2, σ〉 → σ′




σ



σ′′

118 / 141




〈a, σ〉 → v〈x := a, σ〉 → σ[x/v ]

〈p1, σ〉 → σ′ 〈p2, σ′〉 → σ′′

〈p1; p2, σ〉 →

σ′′

〈b, σ〉 → true 〈p1, σ〉 → σ′

〈if b then p1 else p2, σ〉 → σ′〈b, σ〉 → false 〈p2, σ〉 → σ′




σ



σ′′

119 / 141




〈a, σ〉 → v〈x := a, σ〉 → σ[x/v ]

〈p1, σ〉 → σ′ 〈p2, σ′〉 → σ′′

〈p1; p2, σ〉 →

σ′′

〈b, σ〉 → true 〈p1, σ〉 → σ′





σ



σ′′

120 / 141




〈a, σ〉 → v〈x := a, σ〉 → σ[x/v ]

〈p1, σ〉 → σ′ 〈p2, σ′〉 → σ′′

〈p1; p2, σ〉 →

σ′′

〈b, σ〉 → true 〈p1, σ〉 → σ′




〈while b do p od , σ〉 → σ



σ′′

121 / 141




〈a, σ〉 → v〈x := a, σ〉 → σ[x/v ]

〈p1, σ〉 → σ′ 〈p2, σ′〉 → σ′′

〈p1; p2, σ〉 →

σ′′

〈b, σ〉 → true 〈p1, σ〉 → σ′



〈b, σ〉 → false〈while b do p od , σ〉 → σ



σ′′

122 / 141




〈a, σ〉 → v〈x := a, σ〉 → σ[x/v ]

〈p1, σ〉 → σ′ 〈p2, σ′〉 → σ′′

〈p1; p2, σ〉 →

σ′′

〈b, σ〉 → true 〈p1, σ〉 → σ′





〈while b do p od , σ〉 → σ′′

123 / 141




〈a, σ〉 → v〈x := a, σ〉 → σ[x/v ]

〈p1, σ〉 → σ′ 〈p2, σ′〉 → σ′′

〈p1; p2, σ〉 →

σ′′

〈b, σ〉 → true 〈p1, σ〉 → σ′





〈while b do p od , σ〉 → σ′′

124 / 141


Summary:

The operational semantics of IMP is given by:

I Evaluation rules for AExp expressions,

I Evaluation rules for BExp expressions,

I Evaluation rules for P programs expressions,

by using (partial) evaluation relations.

125 / 141

Learning Objectives

I Understanding the task of deductive program verification

I Limitations and trends in deductive program verification

I Familiarize with the Dafny program verifier

I Syntax of the small imperative language IMP

I Operational semantics of IMP

126 / 141

Date post:	17-Jul-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

2em Deductive Verification of Programs · Computer Systems and Correctness I Suppose we design a...

Documents