4: The Hoare

Hoare Logic:

I a to rigorously reason about the correctness of programs I usage to prove correctness “by hand”

I difficult and error prone I doable for small algorithms I unfeasible for large programs I learning goals

I learn the rules of Hoare Logic I apply them to tiny algorithms “by hand” I use a tool applying them for automatic verification (→ section on SPARK) I The goal behind the goals:

I understand how tool-based program verification works (without knowing the HL, you could not reasonably use such tools).

–141– S. Lucks Safe & Secure Software 4: Hoare Logic History

Floyd, 1967: Usage of asserts as a tool for proofs of correctness Hoare, 1969: Axiomatic definition of the program correctness via “Hoare-Triples”:

{Precond.} Program(-fragment) {Postcond.}

Distinction between partial and total correctness Dijkstra 1975: “Weakest precondition” as the foundation for automatically generated proofs – though not with using the computers available in 1975

–142– S. Lucks Safe & Secure Software 4: Hoare Logic partial and total correctness

I Consider a program S, and assume its precondition is satisfied. Notation as a “Hoare Triple”:

{Precondition} S {Postcondition}.

I S is partially correct, if, when it delivers a result, the result satisfies the postcondition. S may not always deliver a result.

I S is totally correct, if it s partially correct and it always terminates (without raising an exception – though Hoare didn’t consider exception in 1969).

I What S does if its precondition is not satisfied, doesn’t affect correctness.

–143– S. Lucks Safe & Secure Software 4: Hoare Logic Examples

Which of the examples is (a) totally correct, (b) partially but not totally correct, or (c) even partially incorrect?

1. {X = 1} null; {X = 0}. 2. {True} X := 1; {X = 0}. 3. {X = 1} null; {X = 1}. 4. {X = 1} loop null; end loop; {X = 0}. 5. {True} X := 1; {X = 1} 6. {False} X := 1; {X = 0}

–144– S. Lucks Safe & Secure Software 4: Hoare Logic Mathematical Proofs

I New proofs are examined carefully when (and even before) they are published (“peer review”).

I Sometimes, people find flaws in proofs published many years before.

–145– S. Lucks Safe & Secure Software 4: Hoare Logic Proofs in Computer Science

I Proof of correctness for Algorithms and Communication Protocols: “peer review”, as in mathematics.

I Proofs of correctness for software (implementation of algorithms): no “peer review”, hardly any incentive.

I The proofs are often not more easy to understand than the source code.

I If the computer can’t verify the proofs – who else will do?

–146– S. Lucks Safe & Secure Software 4: Hoare Logic Correctness

{X ≥ 1} while X > 1 loop if X mod 2 = 0 then X := X / 2; else X := 3∗X + 1; end if; end loop; {X = 1}

I Partial correctness: Yes We Can!

I Total correctness: Unsolved problem from mathematics. I Note: Our “Integers” are mathematical (elements of Z).

–147– S. Lucks Safe & Secure Software 4: Hoare Logic Surprise?

I Given integers X and Y, search for statement(-sequence) S with

{True} S {Y = max(X,Y)}.

Which of these statement(-sequence)s are correct?

I Y := X;

I X := Y;

I X := 0;

I if X > Y then X := Y; end if;

I if X > Y then Y := X; end if;

I X := 0; Y := 0;

Guess which solution is desired? ;-)

–148– S. Lucks Safe & Secure Software 4: Hoare Logic The (perhaps) correct Specification

I Consider

{Xold = X ∧ Yold = Y} S {Y = max(Xold, Yold)}.

with S=”if X > Y then Y := X; end if;”

I This is the excepted behaviour. Observe the “gnost variables”, such as X old and Y old that represent the “old” values of X and Y .

I Also correct, S= “if X > Y then Y := X; else X := Y end if;”

I The defense against changing X:

{Xold = X ∧ Yold = Y} S {X = Xold ∧ Y = max(Xold, Yold)}.

I Classical Hoare logic requires to specify all variables which didn’t change. This scales extremely bad for larger applications!

I Tools avoid that need – e.g., SPARK’s data flow analysis.

–149– S. Lucks Safe & Secure Software 4: Hoare Logic Case study: Sort array A[1..N]

I 1st idea: define S(A) = A[1] ≤ A[2] ≤ · · · A[N]. (S(A)= ”A is sorted”).

{True} Sort(A); {S(A)}

I This is too weak! (why?) What else do we need? old old I 2nd idea: P(A , A)= ”A is a permutation of A ”;

{True} Sort(A); {S(A) ∧ P(Aold, A)}

I This does what we want. But how shall we actually formalize P(Aold, A)?

–150– S. Lucks Safe & Secure Software 4: Hoare Logic 4.1: Building Blocks and a Toy Language

I First order logic

I Two and four other rules to define a “toy language” . . . but a real language can be derived from this

I Logical deduction (application of rules and axioms) to define new rules – and to prove them!

–151– S. Lucks Safe & Secure Software 4: Hoare Logic 4.1: Building Blocks Rule of Composition

P S1 P {P} S1 {R}, {R} S2 {Q} R S1 {P} S ; S ; {Q} R S2 1 2 S2 Q Q

Statements S1 and S2 can merge into S1; S2 if the postcondition of S1 is the same as the precondition for S2. Example:

I S1==={X ≥ 1}X := X + 1; {X ≥ 2}

I S2==={X ≥ 2}X := X/2; {X ≥ 1}

–152– S. Lucks Safe & Secure Software 4: Hoare Logic 4.1: Building Blocks How all rules look like, in general

H1

H2 H1, H2,..., Hn C C

Hn

I “Conclusion” C

I “Hypothesis” H1 ∧ H2, ∧ · · · , ∧Hn

“”: A rule with (H1 ∧ H2, ∧ · · · , ∧Hn) = true.

–153– S. Lucks Safe & Secure Software 4: Hoare Logic 4.1: Building Blocks Rule/Axiom 1: Empty Statement

P True null; {P}null; {P}

P

The axiom ensures that the null; statement doesn’t change the state of the program. Whatever holds true before null; also holds true afterwards, and vice versa.

–154– S. Lucks Safe & Secure Software 4: Hoare Logic 4.1: Building Blocks Axiom 2: Assignment

P[E−>v] True v := E {P[Expr → v]} v := Expr; {P}

P

If P and Expr are expressions, “P[Expr → v]” denotes the expression where all “free” occurrences of v in P are replaced by Expr.

Example:

{2 ∗ X = A}X := 2 ∗ X; {X = A} P === X = A; v === X If the equation X = A shall hold after the assignment, Expr === 2 ∗ X then the equation 2 ∗ X = A must P[Expr → v] === 2 ∗ X = A hold before.

–155– S. Lucks Safe & Secure Software 4: Hoare Logic 4.1: Building Blocks Rule 3: Composition (We have seen that before)

P S1 P {P} S1 {R}, {R} S2 {Q} R S1 {P} S ; S ; {Q} R S2 1 2 S2 Q Q

–156– S. Lucks Safe & Secure Software 4: Hoare Logic 4.1: Building Blocks Rule 4: IF-THEN-ELSE

P

B no yes P ⋀¬ B P ⋀ B {P, B} S1 {Q}, {P, ¬B} S2 {Q} S2 S1 {P} if B then S1; else S2; end if ; {Q}

Q Q Q

–157– S. Lucks Safe & Secure Software 4: Hoare Logic 4.1: Building Blocks Rule 5: WHILE

P ¬ B

P ⋀ B {P, B} S {P} S {P} while B loop S; end loop; {P, ¬B}

P P ⋀¬ B

–158– S. Lucks Safe & Secure Software 4: Hoare Logic 4.1: Building Blocks Rule 6: Conclusion

P ⇒

P' P P ⇒ P0, {P0} S {Q0}, Q0 ⇒ Q S ⇒ S {P} S {Q} Q' Q ⇒

Q

–159– S. Lucks Safe & Secure Software 4: Hoare Logic 4.1: Building Blocks Deriving new rules (1)

Conclusion: P ⇒ P0, {P0} S {Q0}, Q0 ⇒ Q {P} S {Q} Abstract Logic: P ⇒ P and Q0 ⇒ Q. Postcondition Weakening Precondition Strengthening

{P} S {Q0}, Q0 ⇒ Q P ⇒ P0, {P0} S {Q} {P} S {Q} {P} S {Q}

–160– S. Lucks Safe & Secure Software 4: Hoare Logic 4.1: Building Blocks Deriving new rules (2)

Rule of Composition:

{P} S1 {R}, {R} S2 {Q} {P} S1; S2; {Q}

Conclusion: P ⇒ P0, {P0} S {Q0}, Q0 ⇒ Q {P} S {Q} extended Rule of Composition:

0 0 {P} S1 {R}, {R } S2 {Q}, R ⇒ R {P} S1; S2; {Q}

–161– S. Lucks Safe & Secure Software 4: Hoare Logic 4.1: Building Blocks Our Toy Language

Ada-Code Fragments:

I variables of a (mathematical) integer type I expressions

I integer I boolean I statements:

I null; I assignment: variable := integer-expr I sequence of statements I control structures:

I if boolean-expr then statement else statement end if; I while boolean-expr loop statement end loop

–162– S. Lucks Safe & Secure Software 4: Hoare Logic 4.1: Building Blocks 4.2: The WHILE rule is special

{P, B} S {P} {P} whileB loop S; end loop ; {P, ¬B}

1. WHILE separates partial from complete correctness. Note that the language we currently have does not support (recursive) subprograms. 2. WHILE-loops are difficult to prove correct, both manually and (especially) automatically.

–163– S. Lucks Safe & Secure Software 4: Hoare Logic 4.2: WHILE An important tool to analyze loops

P is an invariant of a loop, if it holds before and after each iteration of the loop.

Example:

{Y = 0} whileX > 0 loop Y := Y +1; X := X −1; end loop; {Y = Xold}

What invariant would you use?

–164– S. Lucks Safe & Secure Software 4: Hoare Logic 4.2: WHILE Variant Another tool to analyze loops – for total correctness

An integer expression V is a variant of a loop, 1. if V ≥ 0 and 2. if V decreases during each iteration. Example:

{Y = 0} whileX > 0 loop Y := Y +1; X := X −1; end loop; {Y = Xold}

What is the variant of the loop?

–165– S. Lucks Safe & Secure Software 4: Hoare Logic 4.2: WHILE While-Loop Proof

Example: How would you prove the following code correct? How would you prove it terminates?

while X > 0 loop Y := Y + 1; X := X − 1; end loop;

–166– S. Lucks Safe & Secure Software 4: Hoare Logic 4.2: WHILE 4.3: Verifying Code Fragments

How would you prove the following claim?

{X = Xold, Y = Yold} T := X; X := Y ; Y := T ; {X = Yold, Y = Xold}

–167– S. Lucks Safe & Secure Software 4: Hoare Logic 4.3: Verifying Code Recall the Rules Assignment, Composition, Postcondition Weakening

0 0 True {P} S1 {R}, {R} S2 {Q} {P} S {Q }, Q ⇒ Q {P[Expr→v]} v:=Expr; {P} {P} S1; S2; {Q} {P} S {Q}

The proof:

{X = Xold, Y = Yold} T := X; {T = Xold, X = Xold, Y = Yold}

{T = Xold, X = Xold, Y = Yold} X := Y ; {T = Xold, X = Yold, Y = Yold}

{T = Xold, X = Yold, Y = Yold} Y := T ; {T = Xold, X = Yold, Y = Xold}

{T = Xold, X = Yold, Y = Xold} =⇒ {X = Yold, Y = Xold}

–168– S. Lucks Safe & Secure Software 4: Hoare Logic 4.3: Verifying Code Much Ado about Nothing?

I Much Ado, to prove a triviality.

I Manual proofs are error-prone

–169– S. Lucks Safe & Secure Software 4: Hoare Logic 4.3: Verifying Code Searching for possible proof strategies Something, a computer can do, (mostly) without human intervention

The claim {X = 5} X := 2 ∗ x; {X > 0} is correct, but not tight. I.e., we could replace the precondition by a weaker one, or the postcondition by a stronger one.

There are several weaker preconditions and several stronger postconditions. Which one should the computer choose? The two extreme cases are the following:

Weakest Precondition:X > 0 Strongest Postcondition:X = 10

–170– S. Lucks Safe & Secure Software 4: Hoare Logic 4.3: Verifying Code Strongest Postcondition

Theorem: Let S be a program and P a precondition. Then there exists a unique Q∗ with ∗ I {P} S {Q } ∗ I and for all Qi with {P} S {Qi} it holds that Q ⇒ Qi.

Proof (Sketch): Assume Q1 and Q2 are both postconditions:

{P} S {Q1} and {P} S {Q2}.

Then Q0 = Q1 ∧ Q2 is also a postcondition:

{P} S {Q0}.

Furthermore, Q0 is at least as strong as either Q1 or Q2:

Q0 → Q1 and Q0 → Q2.

Definition:Q ∗ the strongest postcondition.

–171– S. Lucks Safe & Secure Software 4: Hoare Logic 4.3: Verifying Code Weakest Precondition Theorem: Let S be a program amd Q a postcondition. there exists a unique P∗ with ∗ I {P } S {Q} ∗ I for all Pi with {Pi} S {Q} it holds that Pi ⇒ P . Proof: (similar to the strongest postcondition case)

Definition:P ∗ is the weakest precondition.

Remark 1: Though each of the strongest postcondition Q∗ and the weakest precondition P∗ is logically unique, but it can be represented by different expressions. E.g., the the following expressions are logically the same: “X ≥ 0”, “X = abs(X)”, and “X ≥ 1 ∨ X = 0”. Remark 2: In practice, the weakest precondition is preferred over the strongest postcondition.

–172– S. Lucks Safe & Secure Software 4: Hoare Logic 4.3: Verifying Code Weakest precondition calculus For all (deterministic) programs S, the following rules/laws hold:

Miracles excluded: WP(S, False) = False Validity rule: WP(S, True) = True

Conjunction and disjunction:

WP(S, Q) ∧ WP(S, R) = WP(S, Q ∧ R)

WP(S, Q) ∨ WP(S, R) = WP(S, Q ∨ R)

Conclusions:

Fur¨ Q → R: WP(S, Q) → WP(S, R)

–173– S. Lucks Safe & Secure Software 4: Hoare Logic 4.3: Verifying Code How the computer computes WP(·, ·)

Empty Statement: WP(null; , P) = P Assignment: WP(X := Expr; , Q) = Q[Expr → X] Composition: WP(S; T ; , Q) = WP(S, WP(T , Q)) IF-THEN-ELSE:

WP(ifB then S else T end if; , Q) = (B ⇒ WP(S,Q)) ∧ (¬B ⇒ WP(T,Q))

WHILE: WP(whileB loop S end while; , Q) = ???

–174– S. Lucks Safe & Secure Software 4: Hoare Logic 4.3: Verifying Code The woe with WHILE

WP(whileB loop S end while; , Q) = ???

We write cnt(i) for “the loop is iterated exactly i times”, and cnt(∞) for “the loop runs forever”. Write Si for i repetions of S (e.g, S3 = S; S; S;). Then   _ i ??? = cnt(∞) ∨  (cnt(i) ∧ WP(S ; , Q)) i∈{0,1,2,3,4,...} This gives us the WP – but it is hardly useful for our puropses.

–175– S. Lucks Safe & Secure Software 4: Hoare Logic 4.3: Verifying Code WHILE: What to do in practice Consider a loop

{P} whileB loop S end while {Q}

with a precondition {P} and a postcondition {Q}. We need “cut the loop” by a I. We require it to satisfy: 1.P ⇒ I (“I is true before the loop”), 2.I ∧ B → WP(S, I) (“I remains intact under iteration of the loop body”), and 3.I ∧¬ B → Q (“When I holds at loop termination, the postcondition holds”). People usually write a loop with an invariant as

{P} while {I} B loop S end while {Q}

But note that I must hold even if B is false from the beginning. It would be more clear to write {P}{I} whileB loop S {I} end while {Q}.

–176– S. Lucks Safe & Secure Software 4: Hoare Logic 4.3: Verifying Code Examples Assignment, Composition, IF-THEN-ELSE Assignment:

WP(“c := a + b;00 , c = 6) = a + b = 6.

Composition:

WP(“b := a; c := a + b;00 , c = 6) = WP(“b := a;00 , a + b = 6) = a + a = 6.

(logically the same as a = 3).

IF-THEN-ELSE:

WP(“if X >= 0 then null else X := −X; end if;00 , X > 0) = ...

–177– S. Lucks Safe & Secure Software 4: Hoare Logic 4.3: Verifying Code Example WHILE

{Nold = N > 0, M=M ≥ 0} R := 1; S := 0; {Invariant} whileS < M loop R := R ∗ N; S := S + 1; {Invariant} end loop; {Nold = N, Mold = M, R = NM}

–178– S. Lucks Safe & Secure Software 4: Hoare Logic 4.3: Verifying Code How to find loop invariants?

{P, B} S {P} {P} while B loop S; end loop; {P, ¬B}

I The invariant P should hold before the loop, and after each loop iteration. I Informally, it describes that

I what has been achieved by the loop iterations so far I together with what will be achieved by future loop iterations I will provide the claimed result.

–179– S. Lucks Safe & Secure Software 4: Hoare Logic 4.3: Verifying Code Back to the example!

Rule of thumb: {Nold = N > 0, Mold = M ≥ 0} I Take the postcondition and R := 1; S := 0; I describe it as being dependent {Invariant} from the local variables (as whileS < M loop opposed from the input R := R ∗ N; parameters), S := S + 1; I such that when leaving the {Invariant} loop, the invariant is the same end loop; as the postcondition. old old M S {N = N, M = M, R = N } I Here: Invariant := R = N .

–180– S. Lucks Safe & Secure Software 4: Hoare Logic 4.3: Verifying Code Continuing the example

{Nold = N > 0, Mold = M ≥ 0} R := 1; I Are we done? S := 0; I Not quite. We leave the S {R = N } while loop when while S < M loop ¬(S < M) holds. R := R ∗ N; This is equivalent to S := S + 1; I S ≥ M, but {R = NS} end loop; I we would need S = M. {Nold = N, Mold = M, R = NS, S ≥ M}

–181– S. Lucks Safe & Secure Software 4: Hoare Logic 4.3: Verifying Code Finishing the example

I Are we done? old old {N = N > 0, M = M ≥ 0} I Not quite. We leave the R := 1; loop when ¬(S < M) S := 0; holds. {R = NS} I This is equivalent to while S < M loop S ≥ M, but R := R ∗ N; we actually need S := S + 1; I S = M. {R = NS} end loop; I The simplest way to do {Nold = N, Mold = M, R = NS, S = M} so is to write “while S 6= M”.

–182– S. Lucks Safe & Secure Software 4: Hoare Logic 4.3: Verifying Code Two programs to compute the factorial. Which Invariants would you choose?

{X = N, Y = 1} {X = 0, Y = 1} while X 6= 0 loop while X < N loop Y := Y ∗ X; X := X + 1; X := X − 1; Y := Y ∗ X; end loop; end loop; {X = 0, Y = N!} {X ≥ N, Y = N!}

–183– S. Lucks Safe & Secure Software 4: Hoare Logic 4.3: Verifying Code Total Correctness

I to claim total correctness, we write

[P] S [Q]

I this holds, if the partial correctness is given

{P} S {Q}

I and S always terminates (assuming P).

–184– S. Lucks Safe & Secure Software 4: Hoare Logic 4.3: Verifying Code Rules for programs without loops No surprise!

I Replace “{...}” by “[...]” in all axioms and rules – except for WHILE. (We later will elaborate on the assignment axiom . . . )

I If S is without a WHILE loop, this trivially gives

{P} S {Q} [P] S [Q]

–185– S. Lucks Safe & Secure Software 4: Hoare Logic 4.3: Verifying Code WHILE

Consider the following proof: 1. {P} null; {P} (Axiom) 2. {P, P} null; {P} (Precondition Strengthening) 3. {P, P} whileP loop null ; end loop; {P, ¬P} (WHILE) Let us try the easy way: If we just replace “{...}” by “[...]”, we get a a contradition:

[P, P] whileP loop S end loop;[P, ¬P]

No suprise – our loop doesn’t terminate, and our replacement rule is plain wrong for WHILE loops!

–186– S. Lucks Safe & Secure Software 4: Hoare Logic 4.3: Verifying Code WHILE (2)

To prove the termination of whileB loop S end loop; one proves the existence of an integer V ≥ 0, which decreases with every iteration of S. This integer V is the variant.

–187– S. Lucks Safe & Secure Software 4: Hoare Logic 4.3: Verifying Code Back to the old example

{Nold = N > 0, Mold = M ≥ 0} R := 1; S := 0; {R = NS} while S < M loop I What could be the variant? R := R ∗ N; S := S + 1; {R = NS} end loop; {Nold = N, Mold = M, R = NS, S = M}

–188– S. Lucks Safe & Secure Software 4: Hoare Logic 4.3: Verifying Code The assignment: take heed!

For the assignment, we simply replace “{...}” by “[...]”. I.e.,

{P[Expr → v]} v:=Expr; {P}

becomes

[P[Expr → v]] v:=Expr; [P]

which describes the expected behaviour well.

BUT: This assumes that the computation of “Expr” always terminates. For more general languages, which, e.g., allow to call recursive functions in expressions, this is plain wrong.

–189– S. Lucks Safe & Secure Software 4: Hoare Logic 4.3: Verifying Code How to deal with errors e.g., when computing X/Y and Y = 0

1. Just ignore the problem

I X/0 is an arbitrary number, who cares? I But then, why do you need a proof at all? 2. Raise an exception / an error

I may be OK for partial but not for total correctness 3. Continue with some special value

I X/0 may be “Not A Number”, I as will be (X/0) ∗ 0, (X/0) + A,... 4. Defend against such cases in advance

I X/Y enforces Y 6= 0 as an additional precondition I (→ SPARK).

–190– S. Lucks Safe & Secure Software 4: Hoare Logic 4.3: Verifying Code 4.4: Extending the Toy Language IF-THEN-(no-ELSE)

Syntax:

I if B then S end if; Semantic:

I if B then S else null; end if;

–191– S. Lucks Safe & Secure Software 4: Hoare Logic 4.4: Justification

IF-THEN-ELSE:

{P, B} S1 {Q}, {P, ¬B} S2 {Q} {P} if B then S1 else S2 end if ; {Q}

Set S2 = null;:

{P, B} S1 {Q}, {P, ¬B} null; {Q} {P} if B then S1 else null; end if ; {Q} Empty Statement:

{P, B} S {Q} (P ∧¬ B) ⇒ Q {P} if B then S end if ; {Q}

Wow! That was really easy!

–192– S. Lucks Safe & Secure Software 4: Hoare Logic 4.4: REPEAT-UNTIL

Syntax:

I repeat S until B; (∗ this is Pascal ∗) Semantic:

I S while (¬ B) loop S end loop; –– this is Ada

–193– S. Lucks Safe & Secure Software 4: Hoare Logic 4.4: Justification

WHILE: {P, B} S {P} {P} while B loop S end loop; {P, ¬B} This gives {P} S {Q}, {Q, ¬B} S {Q} {P} repeat S until B; {Q, B}

–194– S. Lucks Safe & Secure Software 4: Hoare Logic 4.4: FOR-loops

Syntax: for I in A .. B loop S end loop; Simple semantic for FOR-loops: I :=A; while I ≤ B loop S I := I + 1; end loop;

–195– S. Lucks Safe & Secure Software 4: Hoare Logic 4.4: Semantic Problem – FOR-loops are Difficult There is a problem with our simple semantic:

I FOR-loops should always terminate, unlike WHILE-loops. (There is an obvious variant . . . ).

I But our simple semantic definition allows to write FOR-loops to runing forever. Example: {True} for I in 1 .. 1 loop I := I − 1; end loop; {2 = 1}

I Note: This is the toy language and not Ada. For Ada the assignment to a loop parameter would produce a compiler error.

I With a stricter definition and some constraints (e.g., prohibit assigning a value to the loop counter), the variant for for I in A .. B loop S; end loop; is just B − I + 1.

I Many old programming languages (e.g., Algol-60) lack a sufficiently strict semantic for FOR-loops . . .

I . . . and many new programming languages also (e.g., Java).

–196– S. Lucks Safe & Secure Software 4: Hoare Logic 4.4: Arrays Now it gets even more difficult!

Recall the assignment rule:

{P[Expr → v]} v := Expr; {P}

For assignments related to an array A(...), we get

{P[Expr2 → A(Expr1)]} A(Expr1) := Expr2; {P}.

So where is the problem?

–197– S. Lucks Safe & Secure Software 4: Hoare Logic 4.4: Aliasing Recall {P[Expr2 → A(Expr1)]} A(Expr1) := Expr2; {P}. and define

I P as “(X = Y ) ∧ (A(Y ) = 0)”,

I Expr1 as “X” and I Expr2 as “1”.

Then P[Expr2 → A(Expr1)] reduces to P[1 → A(X)]. and this is just P, since P contains no expression A(X). Thus: {X = Y,...} A(X) := 1; {A(Y) = 0}. Ouch! –198– S. Lucks Safe & Secure Software 4: Hoare Logic 4.4: Aliasing

A(X) and A(Y ) are two different expressions, but can denote the same element of A. In that case, changing either actually changes the other one.

–199– S. Lucks Safe & Secure Software 4: Hoare Logic 4.4: Hoare’s solution

An assignment A(Expr1) := Expr2 is treated as (Expr1) ← Expr2 A := A . (Expr1) ← Expr2 Here A denotes the array, which you get if you replace A(Expr1) by Expr2 and leave all other elements of A unchanged.

–200– S. Lucks Safe & Secure Software 4: Hoare Logic 4.4: Two new axioms

New assignment axiom: (“A(Expr1) is replaced by”):

(Expr1) ← Expr2 A (Expr1) = Expr2.

Addional “Frame”-axiom (“the other elements of A remain unchanged”): IF Expr1 6= Expr3 THEN (Expr1) ← Expr2 A (Expr3) = A(Expr3).

–201– S. Lucks Safe & Secure Software 4: Hoare Logic 4.4: Example: Swap A(X) and A(Y )

{A(X) = Xold, A(Y) = Yold} T := A(X); A(X) := A(Y ); A(Y ) := T ; {A(X) = Yold, A(Y) = Xold}

–202– S. Lucks Safe & Secure Software 4: Hoare Logic 4.4: The proof

{A(X) = Xold, A(Y) = Yold} T := A(X); { A(Y) = Yold(!), T = Xold } (Y) ← T  (X) ← A(Y ) { A (X) = Yold, T = Xold }

A(X) := A(Y ); (Y) ← T { A (X) = Yold, T = Xold } (Y) ← T (Y) ← T { A (X) = Yold, A (Y) = Xold } A(Y ) := T ; {A(X) = Yold, A(Y) = Xold}

–203– S. Lucks Safe & Secure Software 4: Hoare Logic 4.4: Still missing (!)

(Y) ← T  (X) ← A(Y ) A (X) = A(Y)

I Case 1: X 6= Y . (That is easy.)

I Case 2: X = Y . (That is a bit tricky!)

–204– S. Lucks Safe & Secure Software 4: Hoare Logic 4.4: Pointers / access types

I In principle, one can treat the heap like a huge array of storage places.

I But if a program makes significant usage of heap-allocated data, proving properties becomes extremely difficult.

I Current research issue, see, e.g.,: Bertrand Meyer, “The Theory and Calcus of Aliasing”: hhttp://bertrandmeyer.com/2010/01/21/ the-theory-and-calculus-of-aliasing/i

–205– S. Lucks Safe & Secure Software 4: Hoare Logic 4.4: Parameterless procedures

Syntax:

I procedure P is begin S0; end Semantic:

I Whenever P is called, we actually execute S0. Rule for non-recursive parameterless procedures:

{P} S0; {Q} {P} P; {Q}

Nonrecursive procedures (and functions) with parameters, e.g.,

procedure P(X : ...) is S0 end P;

Calling P(Expr) is the same as assigning Expr to X then runing S0.

–206– S. Lucks Safe & Secure Software 4: Hoare Logic 4.4: Functions / Prozedures in general

I Recursive procedures:

I partial correcntess similar to the nonrecursive case I termination needs an upper bound (like the variant for WHILE-loops) for the recursion depth ∗ ∗∗ I Theorem: There is no complete and sound system for any language which combines

I procedures with procedure-parameters (access procedure), I recursion, I statical scoping, I global variables, and I locally defined procedures as procedure-parameters.

I This combination of features is supported by many languages, starting from Algol-60.

—————- ∗ complete: all correct statements are provable ∗∗ sound: no incorrect statements are provable

–207– S. Lucks Safe & Secure Software 4: Hoare Logic 4.4: