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

transcript

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

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

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

SAT/SMT/ FOL

Formula

Correct(Valid)

Incorrect(Unsat)

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

SAT/SMT/ FOL

Formula

Correct(Valid)

Incorrect(Unsat)

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

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

=⇒ 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

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

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 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 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 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

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

When k = 0, then G is an axiom:

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

92 / 141

〈x , σ〉 → σ(x)

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

93 / 141

〈x , σ〉 → σ(x)

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

94 / 141

〈x , σ〉 → σ(x)

〈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〉 →

〈8, σ0〉 → 8

numbers

〈10, σ0〉 → 10

numbers

〈8 + 10, σ0〉 →

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

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〉 →

〈8, σ0〉 → 8

numbers

〈10, σ0〉 → 10

numbers

〈8 + 10, σ0〉 →

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

97 / 141

〈x , σ0〉 →

0locations

〈5, σ0〉 →

5numbers

〈x + 5, σ0〉 →

〈8, σ0〉 → 8

numbers

〈10, σ0〉 → 10

numbers

〈8 + 10, σ0〉 →

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

98 / 141

〈x , σ0〉 → 0locations

〈5, σ0〉 → 5numbers

〈x + 5, σ0〉 → 5sum

〈8, σ0〉 → 8

numbers

〈10, σ0〉 → 10

numbers

〈8 + 10, σ0〉 →

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

99 / 141

〈x + 5, σ0〉 → 5sum

〈8 + 10, σ0〉 → 18sum

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

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

105 / 141

〈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

〈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

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

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

109 / 141

〈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

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

Documents