Hoare logic
Hoare logic (also known as Floyd–Hoare logic or Hoare rules) is a formal system with a set of logical rules for reasoning rigorously about the correctness of computer programs. It was proposed in 1969 by the British computer scientist and logician C. A. R. Hoare, and subsequently refined by Hoare and other researchers.[1] The original ideas were seeded by the work of Robert Floyd, who had published a similar system[2] for flowcharts.
Contents |
Hoare triple [edit]
The central feature of Hoare logic is the Hoare triple. A triple describes how the execution of a piece of code changes the state of the computation. A Hoare triple is of the form
where P and Q are assertions and C is a command [3]. P is named the precondition and Q the postcondition: when the precondition is met, executing the command establishes the postcondition. Assertions are formulae in predicate logic.
Hoare logic provides axioms and inference rules for all the constructs of a simple imperative programming language. In addition to the rules for the simple language in Hoare's original paper, rules for other language constructs have been developed since then by Hoare and many other researchers. There are rules for concurrency, procedures, jumps, and pointers.
Partial and total correctness [edit]
Using standard Hoare logic, only partial correctness can be proven, while termination needs to be proved separately. Thus the intuitive reading of a Hoare triple is: Whenever P holds of the state before the execution of C, then Q will hold afterwards, or C does not terminate. Note that if C does not terminate, then there is no "after", so Q can be any statement at all. Indeed, one can choose Q to be false to express that C does not terminate.
Total correctness can also be proven with an extended version of the While rule.
Rules [edit]
Empty statement axiom schema [edit]
The empty statement rule asserts that the skip statement does not change the state of the program, thus whatever holds true before skip also holds true afterwards.
Assignment axiom schema [edit]
The assignment axiom states that after the assignment any predicate holds for the variable that was previously true for the right-hand side of the assignment. Formally, let P be an expression in which the variable x is free. Then:
where
denotes the expression P in which each free occurrence of x has been replaced by expression E.
The assignment axiom scheme means that the truth of
is equivalent to the after-assignment truth of
. Thus were
true prior to the assignment, by the assignment axiom, then
would be true subsequent to which. Conversely, were
false prior to the assignment statement,
must then be false afterwards.
Examples of valid triples include:
The assignment axiom scheme is equivalent to saying that to find the precondition, first take the post-condition and replace all occurrences of the left-hand side of the assignment with the right-hand side of the assignment. Be careful not to try to do this backwards by following this incorrect way of thinking:
; this rule leads to nonsensical examples like:
Another incorrect rule looking tempting at first glance is
; it leads to nonsensical examples like:
The assignment axiom proposed by Hoare does not apply when more than one name may refer to the same stored value. For example,
is wrong if x and y refer to the same variable, although it is a proper instance of the assignment axiom scheme (with both
and
being
).
Rule of composition [edit]
Hoare's rule of composition applies to sequentially executed programs S and T, where S executes prior to T and is written S;T (Q is called the midcondition):[4]
For example, consider the following two instances of the assignment axiom:
and
By the sequencing rule, one concludes:
Conditional rule [edit]
The conditional rule states that a postcondition
common to then and else part is also a postcondition of the whole if...endif statement. In the then and the else part, the unnegated and negated condition
can be added to the precondition
, respectively. An example is given in the next section.
It was not contained in Hoare's original publication [1]. However, since a statement
has the same effect as a one-time loop construct
the conditional rule can be derived from the other Hoare rules. In a similar way, rules for other derived program constructs, like for loop, do...until loop, switch, break, continue can be reduced by program transformation to the rules from Hoare's original paper.
Consequence rule [edit]
This rule allows to strenghten the precondition and/or to weaken the postcondition. It is used e.g. to achieve literally identical postconditions for then then and the else part.
For example, a proof of
- Failed to parse (lexing error): \{0≤x≤15\} \;\;\; \textbf{if} \; x<15 \; \textbf{then} \; x:=x+1 \; \textbf{else} \; x:=0 \; \textbf{endif} \;\;\; \{0≤x≤15\}
needs to apply the conditional rule, which in turn requires to prove
- Failed to parse (lexing error): \{0≤x≤15 \land x<15\} \;\;\; x:=x+1 \;\;\; \{0≤x≤15\} \;\;\;
, or simplified
- Failed to parse (lexing error): \{0≤x<15\} \;\;\; x:=x+1 \;\;\; \{0≤x≤15\}
for the then part, and
- Failed to parse (lexing error): \{0≤x≤15 \land x≥15\} \;\;\; x:=0 \;\;\; \{0≤x≤15\} \;\;\;
, or simplified
- Failed to parse (lexing error): \{x=15\} \;\;\; x:=0 \;\;\; \{0≤x≤15\}
for the else part.
However, the assignment rule for the then part requires to chose
as Failed to parse (lexing error): 0≤x≤15
- rule application hence yields
- Failed to parse (lexing error): \{0≤x+1≤15\} \;\;\; x:=x+1 \;\;\; \{0≤x≤15\} \;\;\;
, which is logically equivalent to
- Failed to parse (lexing error): \{-1≤x<15\} \;\;\; x:=x+1 \;\;\; \{0≤x≤15\}
. The consequence rule is needed to strenghten the precondition Failed to parse (lexing error): \{-1≤x<15\}
obtained from the assignment rule to Failed to parse (lexing error): \{0≤x<15\}
required for the conditional rule.
Similarly, for the else part, the assignment rule yields
- Failed to parse (lexing error): \{0≤0≤15\} \;\;\; x:=0 \;\;\; \{0≤x≤15\} \;\;\;
, or equivalently
- Failed to parse (lexing error): \{true\} \;\;\; x:=0 \;\;\; \{0≤x≤15\}
, hence the consequence rule has to be applied with
and
being
and
, respectively, to strengthen again the precondition. Informally, the effect of the consequence rule is to "forget" that
is known at the entry of the else part, since the assignment rule used for the else part doesn't need that information.
While rule [edit]
Here
is the loop invariant, which is to be preserved by the loop body
. After the loop is finished, this invariant
still holds, and moreover
must have caused the loop to end.
For example, a proof of
- Failed to parse (lexing error): \{x≤10\} \;\;\; \textbf{while} \; x<10 \; \textbf{do} \; x:=x+1 \; \textbf{done} \;\;\; \{\neg x<10 \land x≤10\}
by the while rule requires to prove
- Failed to parse (lexing error): \{x≤10 \land x<10\} \;\;\; x:=x+1 \;\;\; \{x≤10\} \;\;\;
, or simplified
- Failed to parse (lexing error): \{x<10\} \;\;\; x:=x+1 \;\;\; \{x≤10\}
, which is easily obtained by the assignment rule. Finally, the postcondition Failed to parse (lexing error): \{\neg x<10 \land x≤10\}
can be simplified to.
For another example, the while rule can be used to formally verify the following strange program to compute the exact square root
of an arbitrary number
- even if
is an integer variable and
is not a square number:
- Failed to parse (lexing error): \{\textbf{true}\} \;\;\; \textbf{while} \; x*x≠a \; \textbf{do} \; \textbf{skip} \; \textbf{done} \;\;\; \{x*x=a \land \textbf{true}\}
After applying the while rule with
being true, it remains to prove
- Failed to parse (lexing error): \{\textbf{true} \land x*x≠a\} \;\;\; \textbf{skip} \;\;\; \{\textbf{true}\}
, which follows from the skip rule and the consequence rule.
In fact, the strange program is partially correct: if it happened to terminate, it is certain that
must have contained (by chance) the value of
's square root. However, it is not totally correct, since it obviously will not terminate under allmost all circumstances.
While rule for total correctness [edit]
If the above ordinary while rule is replaced by the following one, the Hoare calculus can also be used to prove total correctness, i.e. termination as well as partial correctness. Commonly, square brackets are used here instead of curly braces to indicate the different notion of program correctness.
In this rule, in addition to maintaining the loop invariant, one also proves termination by way of a expression t, called the loop variant, whose value strictly decreases with respect to a well-founded relation
on some domain set
during each iteration. Since
is well-founded, a strictly decreasing chain of members of
can have only finite length, so t cannot keep decreasing forever. (For example, the usual order
is well-founded on the set of positive integer numbers, but neither on the set of all integers nor on the set of positive real numbers; all sets are meant in the mathematical, not in the computing sense, they are all infinite in particular.)
Given the loop invariant P, the condition B must imply that t is not a minimal element of
, for otherwise the body
could not decrease
any further, i.e. the premise of the rule would be false. (This is one of various notations for total correctness.)
Resuming the first example of the previous section, for a total-correctness proof of
- Failed to parse (lexing error): [x≤10] \;\;\; \textbf{while} \; x<10 \; \textbf{do} \; x:=x+1 \; \textbf{done} \;\;\; [\neg x<10 \land x≤10]
the while rule for total correctness can be applied with e.g.
being the positive integers with the usual order, and the expression
being
, which then in turn requires to prove
- Failed to parse (lexing error): [x≤10 \land x<10 \land 10-x≥0 \land 10-x=z] \;\;\; x:=x+1 \;\;\; [x≤10 \land 10-x≥0 \land 10-x<z]\;\;\;
Informally speaking, we have to prove that the distance
decreases in every loop cycle, while it always remains non-negative; this process can go on only for a finite number of cycles.
The previous proof goal can be simplfied to
- Failed to parse (lexing error): [x<10 \land 10-x=z] \;\;\; x:=x+1 \;\;\; [x≤10 \land 10-x<z]
, which can be proven as follows:
- Failed to parse (lexing error): [x+1≤10 \land 10-x-1<z] \;\;\; x:=x+1 \;\;\; [x≤10 \land 10-x<z] \;\;\;
is obtained by the assignment rule, and
- Failed to parse (lexing error): [x+1≤10 \land 10-x-1<z]\;\;\;
can be strenghtened toby the consequence rule.
For the second example of the previous section, of course no expression t can be found that is decreased by the empty loop body, hence termination cannot be proved.
Examples [edit]
-
Example 1 


(Assignment Axiom) 



(Consequence Rule) Example 2 


(Assignment Axiom) (
for x, N with integer types)


(Consequence Rule)
See also [edit]
- Communicating sequential processes
- Design by contract
- Denotational semantics
- Dynamic logic
- Edsger W. Dijkstra
- Loop invariant
- Assertion (computing)
- Predicate transformer semantics
- Program verification
- Refinement calculus
- Separation logic
- Sequent calculus
- Static code analysis
References [edit]
- ^ a b Hoare, C.A.R. (October 1969). "An axiomatic basis for computer programming". Communications of the ACM 12 (10): 576–585. doi:10.1145/363235.363259.
- ^ R. W. Floyd. "Assigning meanings to programs." Proceedings of the American Mathematical Society Symposia on Applied Mathematics. Vol. 19, pp. 19–31. 1967.
- ^ Hoare originally wrote "
" rather than "
". - ^ Huth, Michael; Ryan, Mark. Logic in Computer Science (second ed.). CUP. p. 276. ISBN 052154310X.
Further reading [edit]
- Robert D. Tennent. Specifying Software (a textbook that includes an introduction to Hoare logic, written in 2002) ISBN 0-521-00401-2
External links [edit]
- KeY-Hoare is a semi-automatic verification system built on top of the KeY theorem prover. It features a Hoare calculus for a simple while language.
- j-Algo-modul Hoare calculus — A visualisation of the Hoare calculus in the algorithm visualisation program j-Algo


![\frac{}{\{P[E/x]\}\ x:=E \ \{P\} } \!](http://upload.wikimedia.org/math/0/b/9/0b9a2415175302dce994af21a9218367.png)














.
![\frac { < \textrm{is a well-founded ordering on the set } D, \;\;\;\;\; [P \land B \land t \in D \land t = z ] \;\;\; S \;\;\; [P \land t \in D \land t < z ]}
{ [P] \;\;\; \textbf{while}\ B\ \textbf{do}\ S\ \textbf{done} \;\;\; [\neg B \land P] }
\!](http://upload.wikimedia.org/math/0/e/b/0eb23e9041b8527fff75a1bee12ec466.png)
by the consequence rule.









for x, N with integer types)
" rather than "