An Outline of Separation Logic

TL;DR

This paper introduces Separation Logic, an extension of Hoare Logic, designed to effectively reason about programs with pointers and aliasing issues, using new assertions and axioms to improve proof techniques.

Contribution

It presents the formalization of Separation Logic with new assertions and axioms, demonstrating its application to pointer-manipulating programs and addressing aliasing problems.

Findings

Separation Logic effectively handles aliasing in pointer programs.

New assertions and axioms facilitate proofs of real pointer programs.

Illustrative examples demonstrate the logic's unique features.

Abstract

Separation Logic is an effective Program Logic for proving programs that involve pointers. Reasoning with pointers becomes difficult especially when there is aliasing arising due to several pointers to a given cell location. In this paper, we try to explore the problems with aliasing through some simple examples and introduce the notion of separating conjunction as a tool to deal with it. We introduce Separation Logic as an extension of the standard Hoare Logic with the help pf a programming language that has four pointer manipulating commands. These commands perform the usual heap operations such as lookup, update, allocation and deallocation. The new set of assertions and axioms of Separation Logic is presented in a semi-formal style. Examples are given to illustrate the unique features of the new assertions and axioms. Finally the paper concludes with the proofs of some real programs using the axioms of Separation Logic.

Full text

1 Introduction

The goal of any Program Logic is to help in developing logically correct programs without the need for debugging. Separation Logic [7] is one such Program Logic. I can be seen as an extension to the standard Hoare Logic [1]. The goal of this extension is to simplify reasoning with programs that involve low level memory access, such as pointers.

• •

Reasoning with pointers becomes very difficult because of the way it interfere with the modular style of program development.

Structured programming approaches provide the freedom to develop a large program by splitting it into small modules. Hence, at any given time a programmer can only concentrate on developing a particular module against its specification. In the absence of pointer commands, the proof of correctness of these small modules can easily be extended to a global proof for the whole program.

• •

For example, consider the specification

$\{x=4\}$  x:= 8  $\{x=8\}$

in Hoare triple. It claims that if execution of the command x:= 8 begins in a state where $x=4$ is true, then it ends in a state where $x=8$ is true. This seems trivially true. In a similar way, one can easily verify the validity of following specification:

$\{x=4\wedge y=4\}$  x:= 8   $\{x=8\wedge y=4\}$

Here, the proposition $y=4$ should remain true in the postcondition, since the value of variable $y$ is not affected by the execution of command x:= 8.

• •

The reasoning above is an instance of a more general rule of Hoare logic, called the rule of constancy

$\dfrac{\{p\}\,\,c\,\,\{q\}}{\{p\wedge r\}\,\,c\,\,\{q\wedge r\}}$

where, no free variable of $r$ is modified by $c.$ It is easy to see how this rule follows from the usual meaning of the assignment operator. Following sequence of state transition can be used to illustrate the above idea:

[TABLE]

However, if the program modules uses data structures such as arrays, linked lists or trees, which involves the addressable memory, then extending the local reasoning is not so easy using the rule of constancy.

• •

For example, consider a similar specification which involves mutation of an array element

$\{a\left[i\right]=4\wedge a\left[j\right]=4\}$ a[i]:= 8 $\{a\left[i\right]=8\wedge a\left[j\right]=4\}$

It is not a valid specification. Consider the case when $i=j$. Therefore an extra clause $i\neq j$ is needed in the precondition to make it a valid specification. To complicate the situation even further, consider the following specification

$\{a\left[i\right]=4\wedge a\left[j\right]=4\wedge a\left[k\right]=4\}$ a[i]:= 8 $\{a\left[i\right]=8\wedge a\left[j\right]=4\wedge a\left[k\right]=4\}$

In this case two more clauses i,e. $i\neq j$ and $i\neq k$ are needed in the precondition to make it a valid specification. These are the extra clauses, that a programmer often forgets to mention. However these clauses are necessary since it assures that the three propositions $a[i]=4$ , $a[j]=4$ and $a[k]=4$ refer to the mutually disjoint portion of the heap memory and hence mutating one will not affect the others. Thus, although $\{a\left[i\right]=4\}$ a[i]:= 8 $\{a\left[i\right]=8\}$ is a valid specification, applying rule of constancy in these cases can lead us to an invalid conclusion.

These kind of non-sharing is often assumed by programmers. However, in classical logic non sharing need explicit mention, which results in a program specification that looks clumsy.

• •

Separation logic deals with this difficulty by introducing a separating conjunction, $P*Q$, which asserts that $P$ and $Q$ holds for disjoint portions of the addressable memory.

• •

In this sense it is more close to the programmers way of reasoning.

Since non sharing is default in separating conjunction, the above specification can be written succinctly as

$\{a\left[i\right]\mapsto 4*a\left[j\right]\mapsto 4*a\left[k\right]=4\}$ a[i]:= 8 $\{a\left[i\right]\mapsto 8*a\left[j\right]\mapsto 4*a\left[k\right]\mapsto 4\}$

where, $p\mapsto e$ represents a single cell heap-let with $p$ as domain and $e$ is the value stored at the address $p$. Thus the assertion $a\left[i\right]\mapsto 4*a\left[j\right]\mapsto 4$ means that $a\left[i\right]\mapsto 4$ and $a\left[j\right]\mapsto 4$ holds on disjoint parts of the heap and hence $i\neq j$. Although, the normal rule of constancy is no more valid, we have the following equivalent rule called “frame rule”

$\dfrac{\{p\}\,\,c\,\,\{q\}}{\{p*r\}\,\,c\,\,\{q*r\}}$

where, no variable occurring free in $r$ is modified by $c$.

In this section, we have seen some specifications and their meanings in a semi-formal way. We need to define these notions formally, before we can discuss new assertions and other features of separation logic more rigorously. Section 2, prepares this background by defining a language $\mathcal{L}$ and introducing Hoare Logic. Section 3, introduces the new forms of assertions in Separation Logic. It also extends axioms of Hoare Logic to include some new axioms for reasoning with pointers. In Section 4, we describe the idea of annotated proofs and present the proof of an in-place list reversal program using the axioms of Separation logic.

2 Background

In this section, we fix a language $\mathcal{L}$ by defining its syntax and semantics. A subset $S$ of the language $\mathcal{L}$ is then used to introduce the axioms of Hoare Logic for commands that doesn’t involve pointers. We now describe the structure and meaning of various commands in the language $\mathcal{L}$:

• •

**Skip.

**Command: skip

Meaning: The execution has no effect on the state of computation.

• •

Assignment.

Command: x:= e

Meaning: The command changes the state by assigning the value of term $e$ to the variable $x$.

• •

**Sequencing.

**Command: $C_{1};\dots;C_{n}$

Meaning: The commands $C_{1},\dots,C_{n}$ are executed in that order.

• •

Conditional.

Command: if b then $C_{1}$else $C_{2}$

Meaning: If the boolean expression $b$ evaluates to true in the present state, then $C_{1}$ is executed. If $b$ evaluates to false, then $C_{2}$ is executed.

• •

While-Loop.

Command: while b do $C$

Meaning: If the boolean expression $b$ evaluates to false then nothing is done. If $b$ evaluates to true in the present state, then $C$ is executed and the while command is then repeated. Hence, $C$ is repeatedly executed until the value of $b$ becomes false.

• •

Allocation.

Command: x:=cons($e_{1},\dots,e_{n}$)

Meaning: The command x:=cons($e_{1},\dots,e_{n}$) reserves $n$ consecutive cells in the memory initialized to the values of $e_{1},\dots,e_{n}$, and saves in $x$ the address of first the cell. Note that, for the successful execution of this command the addressable memory must have $n$ uninitialized and consecutive cells available.

• •

**Lookup.

**Command: x:= [e]

Meaning: It saves the value stored at location $e$ in the variable $x$. Again for the successful execution of this command location $e$ must have been initialized by some previous command of the program. Otherwise, the execution will abort.

• •

**Mutation.

**Command:[e]:= e’

Meaning: The command [e]:= e’, stores the value of expression $e^{\prime}$ at the location $e$. Again, for this to happen, location $e$ must be an active cell of the addressable memory.

• •

**Deallocation.

**Command: free (e)

Meaning: The instruction free (e) , deallocates the cell at the address $e$. If $e$ is not an active cell location, then the execution of this command shall abort.

2.1 Formal Syntax

The structure of commands in the language $\mathcal{L}$ can also be described by the following abstract syntax:

Syntax of Command

{grammar}

<cmd> ::= ‘skip’ \alt<var> := <aexp> \alt<cmd> ‘;’ <cmd> \alt‘if’ <bexp> ‘then’ <cmd> ‘else’ <cmd> \alt‘while’ <bexp> ‘do’ <cmd> \alt<var> := ‘cons’ (<aexp>,…, <aexp>) \alt<var> := [<aexp>] \alt[<aexp>] := <aexp> \alt‘free’ (<aexp>) Where aexp and bexp stands for arithmetic and boolean expressions respectively. The syntax of these are as follows: {grammar} <aexp> ::= int \alt<var> \alt<aexp> + <aexp> \alt<aexp> - <aexp> \alt<aexp> $\times$ <aexp>

{grammar}

<bexp> ::= true | false \alt<aexp> = <aexp> \alt$\neg$ <bexp> \alt<bexp> $\wedge$ <bexp> \alt<bexp> $\vee$ <bexp> \alt<bexp> $\Rightarrow$ <bexp>

2.2 Formal Semantics

The formal semantics of a programming language can be specified by assigning meanings to its individual commands. A natural way of assigning meaning to a command is by describing the effect of its execution on the state of computation. The State of a computation can be described by its two components, store and heap.

• •

Store, which is sometimes called stack, contains the values of local variables. Heap maintains the information about the contents of active cell locations in the memory. More precisely, both of them can be viewed as partial functions of the following form:

[TABLE]

• •

Note that the notations, cons and $[-]$, which refer to the heap memory, are absent in the syntax of aexp. Therefore, the evaluation of an arithmetic or boolean expression depends only on the contents of the store at any given time. We use the notation $s\models e\Downarrow v$ to assert that the expression $e$ evaluates to $v$ with respect to the content of store $s$. For example, let $s=\{(x,2),(y,4),(z,6)\}$ then $s\models x\times(y+z)\Downarrow 20$ . For our discussion, we assume that this evaluation relation is already defined.

Operational Semantics:

We now define a transition relation, represented as $\left\langle c,(s,h)\right\rangle\,\,\rightarrowtail(s^{\prime},h^{\prime})$, between states. It asserts that, if the execution of command $c$ starts in a state $(s,h)$, then it will end in the state $(s^{\prime},h^{\prime})$. The following set of rules, SEMANTICS-I and -II, describes the operational behavior of every command in the language $\mathcal{L}$, using the transition relation $\rightarrowtail$.

[TABLE]

[TABLE]

Where, $f[x:v]$ represents a function that maps $x$ to $v$ and all other argument $y$ in the domain of $f$ to $f\,y$. Notation $f\rceil A$ is used to represent the restriction of function $f$ to the domain $A$.

• •

An important feature of the Language $\mathcal{L}$ is that, any attempt to refer to an unallocated address causes the program execution to abort. For example, consider the following sequence of commands,

[TABLE]

here, an attempt to mutate the content of address $11$ causes the execution to abort, because this location was deallocated by the previous instruction.

2.3 Hoare Triple

The operational semantics of language $\mathcal{L}$ can be used to prove any valid specification of the form $\left\langle c,(s,h)\right\rangle\,\,\overset{*}{\rightarrowtail}\,(s^{\prime},h^{\prime})$. However, this form of specification is not the most useful one. Usually, we do not wish to specify programs for single states. Instead, we would like to talk about a set of states and how the execution may transform that set. This is possible using a Hoare triple $\{p\}c\{q\}$,

• •

Informally, it says that if the execution of program $c$ begins in a state that satisfies proposition $p$ then if the execution terminates it will end in a state that satisfies $q$.

where $p$ and $q$ are assertions that may evaluate to either true or false in a given state. We will use notation $[\![p]\!]\,\,s\,h$, to represent the value to which $p$ evaluates, in the state $(s,h)$. Therefore,

• •

$\{p\}c\{q\}$ holds iff $\forall(s,h)\in\textsf{States},\,[\![p]\!]\,s\,h$ $\implies$

\neg(\left\langle c,(s,h)\right\rangle\overset{*}{\rightarrowtail}\textbf{abort})\,\wedge\,(\forall(s^{\prime},h^{\prime})\in\textsf{States, (\left\langle c,(s,h)\right\rangle\overset{*}{\rightarrowtail}(s^{\prime},h^{\prime})$)$\implies$$[![q]!]}s^{\prime}h^{\prime}).

Now, we can use Hoare triples, to give rules of reasoning for every individual commands of the language $\mathcal{L}$. It is sometimes also called the axiomatic semantics of the language. These rules in a way give an alternative semantics to the commands.

Axiomatic Semantics:

Consider the following set of axioms (AXIOM-I) and structural rules for reasoning with commands, that does not use pointers. Here, $Q[e/x]$ represents the proposition $Q$ with every free occurrence of $x$ replaced by the expression $e$, $Mod(c)$ represents the set of variables modified by $c$, and $Free(R)$ represents the set of free variables in $R$.

[TABLE]

[TABLE]

• •

For the subset of language $\mathcal{L}$, that does not use pointers, these axioms and structural rules are known to be sound as well as complete [10] with respect to the operational semantics.

• •

The benefit of using these axioms is that, we can work on a more abstract level specifying and proving program correctness in an axiomatic way without bothering about low level details of states.

• •

Note that, the last four commands of the language $\mathcal{L}$, which manipulate pointers, are different from the normal variable assignment command. Their right hand side is not an expression. Therefore, Hoare-assign rule is not applicable on them.

Array Revisited:

Now, let us go back to the same array assignment problem which we discussed in the introduction. Let $Q$ be the postcondition for the command a[i]:= 8, where a[i] refers to the $i^{th}$ element of array.

• •

In our language $\mathcal{L}$ this is same as command [a+i]:= 8, however, for convenience we will continue with the usual notation of array.

The command a[i]:= 8 looks similar to the variable assignment command. But, we can not apply Hoare-assign rule to get $Q[8/\texttt{a[i]}]$ as weakest precondition. One should not treat a[i] as a local variable, because the assertion $Q$ may contain references such as a[j] that may or may not refer to a[i]. Instead, we can model the above command as a:=update(a,i,8), where update(a,i,8)$[i]=8$ and update(a,i,8)$[j]=$a$[j]$ for $j\neq i$.

• •

That is, the effect of executing a[i]:= v is same as assigning variable a an altogether new array value ‘‘update (a,i,v)’’.

• •

In this way, a is acting like a normal variable, hence we have the following rule for array assignment,

array-assign$\dfrac{}{\{Q[\texttt{update(a,i,v)/a}]\}\texttt{ a[i]:= v }\{Q\}}$

Let us try to prove the following specification using above rule,

$\{i\neq j\wedge a\left[i\right]=4\wedge a\left[j\right]=4\}$ a[i]:=8 $\{a\left[i\right]=8\wedge a\left[j\right]=4\wedge i\neq j\}$.

Let $P$ =$\{i\neq j\wedge a\left[i\right]=4\wedge a\left[j\right]=4\}$ and $Q$ = $\{a\left[i\right]=8\wedge a\left[j\right]=4\wedge i\neq j\}$.

Then we have, $Q$ [update(a,i,8)/a]

=$\{\texttt{update(a,i,8)}\left[i\right]=8\wedge\texttt{update(a,i,8)}\left[j\right]=4\wedge i\neq j\}$

=$\{8=8\wedge\,a[j]=4\wedge i\neq j\}$

=$\{a[j]=4\,\wedge\,\,i\neq j\}$

Thus,

[TABLE]

Hence, we have a correct rule for deducing valid specifications about array assignments. However, the approach looks very clumsy.

• •

We still need to fill every minute detail of index disjointness in the specification.

• •

Moreover, it seems very artificial to interpret a local update to an array cell as a global update to the whole array. At least, it is not the programmer’s way of understanding an array element update.

• •

The idea of separation logic is to embed the principle of such local actions in the separating conjunction. It helps in keeping the specifications succinct by avoiding the explicit mention of memory disjointness.

3 New Assertions and Inference Rules

In this section, we present the axioms corresponding to the pointer manipulating commands. The set of assertions, which we use for this purpose, goes beyond the predicates used in the Hoare- Logic. Following is the syntax of the new assertions,

{grammar}

<assert> ::= …\altemp \alt<aexp> $\mapsto$ <aexp> \alt<assert> $*$ <assert> \alt<assert> $-*$ <assert>

It is important to note that the meaning of these new assertions depends on both the store and the heap.

[TABLE]

For convenience, we introduce few more notations for the following assertions:

[TABLE]

We now consider a simple example to explore some of the interesting features of separating conjunction. Let $h_{1}=\{(sx,1)\}$ and $h_{2}=\{(sy,2)\}$ be heaps where $s$ is a store such that $sx\neq sy$. Then, one can verify the following

[TABLE]

Assertions 2 and 3 illustrates the difference between the behavior of the classical conjunction and the separating conjunction. Both the occurrence of $x\mapsto 1$ in the assertion $[\![x\mapsto 1*x\mapsto 1]\!]\,\,s\,h$ is true for the same singleton heap $h_{1}$. Hence any heap $h$, can never be split into two disjoint parts that satisfies $x\mapsto 1$. One can also compare assertions 3 and 6, which looks similar in structure but have different behaviors.

The separating conjunction obeys commutative, associative, and some distributive as well as semi-distributive laws. The assertion emp behaves like a neutral elements. Most of these properties are contained in the following axiom schemata. Note the use of one directional implications in $(p_{1}\wedge p_{2})*q\implies(p_{1}*q)\wedge(p_{2}*q)$ and $(\forall x.p)*q\implies\forall x.(p*q)$.

[TABLE]

New Axioms for pointers:

The axioms needed to reason about pointers are given below. There is one axiom for every individual command.

[TABLE]

• allocate

The first axiom, called alloc, uses variable $X$ in its precondition to record the value of $x$ before the command is executed. It says that if execution begins with empty heap and a store with $x=X$ then it ends with $k$ contiguous heap cells having appropriate values.

• lookup

The second axiom, called lookup, again uses $X$ to refer to the value of $x$ before execution. It asserts that the content of heap is unaltered. The only change is in the store where the new value of $x$ is modified to the value at old location $e$.

• mutate

The third axiom, called mut, says that if $e$ points to something beforehand, then it points to $e^{\prime}$ afterward. This resembles the natural semantics of Mutation.

• free

The last axiom, called free, says that if $e$ is the only allocated memory cell before execution of the command then in the resulting state there will be no active cell. Note that, the singleton heap assertion is necessary in precondition to assure emp in the postcondition.

• frame

The last rule among the structural rules, called frame, says that one can extend local specifications to include any arbitrary claims about variables and heap segments which are not modified or mutated by $c$. The frame rule can be thought as an replacement to the rule of constancy when pointers are involved.

[TABLE]

• •

Note that the expressions are intentionally kept free from the cons and [-] operators. The reason for this restriction is that, the power of the above proof system strongly depends upon the ability to use expression in place of variables in an assertion.

• •

In particular, a tautology should remain a valid assertion on replacing variables with expressions.

• •

If we could substitute cons $(e_{1},e_{2})$ for $x$ in the tautology $x=x$, we obtain cons$(e_{1},e_{2})=$cons$(e_{1},e_{2})$, which may not be a valid assertion if we wish to distinguish between different addresses having the same content.

• •

Similarly [-] can not be used in expressions because of the way it interact with separating conjunction. For example consider substituting $[e]$ for $x$ and $y$ in the tautology $x=x\,*\,y=y$. Clearly, $[e]=[e]\,\,*\,\,[e]=[e]$ is not a valid assertion.

• •

Note that each axiom mentions only the portion of heap accessed by the corresponding command. In this sense the axioms are local. Hence a separate rule, called frame rule, is needed to extend these local reasoning for a global context.

• •

These axioms can easily be proved to be sound with respect to the operational semantics of the language $\mathcal{L}$.

• •

Moreover, Yang in his thesis [6] has shown that all valid Hoare triples can be derived using the above collection of axioms and the structural rules. In this sense these set of axioms and structural rules are also complete.

Derived Rules:

Although the small set of rules discussed so far is complete, it is not practical. Proving a specification using this small set of axioms often requires extensive invocation of the structural rules. Therefore, it is good to have some derived rules that can be applied at once in common situations. We now list some other useful rules that can be derived from the natural semantics of the language $\mathcal{L}$. A more detailed discussion about these rules can be found in [9]. Note that $x,\,\,x^{\prime}$ and $X$ are all distinct variables.

• •

Assignment

• –

Forward reasoning

$\dfrac{}{\{x=X\}\texttt{ x:= e }\{x=e[X/x]\}}$

• –

Floyd’s forward running axiom

$\dfrac{}{\{P\}\texttt{ x:= e }\{\exists x^{\prime}.x=e[x^{\prime}/x]\wedge P[x^{\prime}/x]\}}$

• •

Mutation

• –

Global reasoning

\dfrac{}{\{(e\mapsto-)*r\}\texttt{ [e]:= e{}^{\prime}}\{(e\mapsto e^{\prime})*r\}}

• –

Backward reasoning

$\dfrac{}{\{(e\mapsto-)*((e\mapsto e^{\prime})-\!\!*\,\,p)\}\texttt{ [e]:= e' }\{p\}}$

• •

Free

• –

Global (backward) reasoning

$\dfrac{}{\{(e\mapsto-)*r\}\texttt{ free(e) }\{r\}}$

• •

Allocation

• –

Global reasoning (forward)

\dfrac{}{\{r\}\texttt{ x:= cons(e_{1},\dots,e_{k}) }\{\exists x^{\prime}.(x\mapsto e_{1}[x^{\prime}/x],\dots,e_{k}[x^{\prime}/x])*r[x^{\prime}/x]\}}

• –

Backward reasoning

\dfrac{}{\{\forall x^{\prime}.(x^{\prime}\mapsto e_{1},\dots,e_{k})-\!\!*\,\,p[x^{\prime}/x]\}\texttt{ x:= cons(e_{1},\dots,e_{k}) }\{p\}}

• •

Lookup

• –

Global reasoning

$\dfrac{}{\{\exists x^{\prime\prime}.(e\mapsto x^{\prime\prime})*r[x/x^{\prime}]\}\texttt{ x:= [e] }\{\exists x^{\prime}.(e[x^{\prime}/x]\mapsto x)*r[x/x^{\prime\prime}]\}}$

here $x$, $x^{\prime}$ and $x^{\prime\prime}$ are distinct, $x^{\prime}$ and $x^{\prime\prime}$ do not occur free in $e$, and $x$ is not free in $r$.

• –

Backward reasoning

$\dfrac{}{\{\exists x^{\prime}.(e\mapsto x^{\prime})*((e\mapsto x^{\prime})-\!\!*\,\,p[x^{\prime}/x])\}\texttt{ x:= [e] }\{p\}}$

4 Annotated proofs

Proof outlines:

We have already used assertions in Hoare-triples to state what is true before and after the execution of an instruction. In a similar way, an assertion can also be inserted between any two commands of a program to state what must be true at that point of execution. Placing assertions in this way is also called annotating the program.

For example, consider the following annotated program that swaps the value of variable x and y using a third variable z. Note the use of $X$ and $Y$ to represent the initial values of variable $x$ and $y$ respectively.

[TABLE]

Validity of each Hoare-triple in the above program can easily be checked using axioms for assignment. Hence one concludes that the program satisfies its specification.

• •

A program together with an assertion between each pair of statement is called a fully annotated program.

• •

One can prove that a program satisfies its specification by proving the validity of every consecutive Hoare-triple which is present in its annotated version. Hence, a fully annotated program provides a complete proof outline for the program.

Now, we consider another annotated program that involves assertions from the separation logic. Note that the assertion $(x\mapsto a,o)*(x+o\mapsto b,-o)$ can be used to describe a circular offset-list. Here is a sequence of commands that creates such a cyclic structure:

[TABLE]

The above proof outline illustrates two important points.

• •

First, a label is used against each assertion so that referring becomes easy in the future discussions.

• •

Secondly, the adjacent assertions - e.g. here the assertions 5 and 6 - mean that the first implies the second.

Also, note the use of $*$ in assertions 3. It insures that $x+1$ is different from $t$ and $t+1$, and hence the assignment $[x+1]\texttt{:= }t-x$ cannot affect the $t\mapsto b,b$ clause. A similar reasoning applies for the last command as well.

Inductive definitions:

When reasoning about programs which manipulate data structure, we often need to use inductively defined predicates describing such structures. For example, in any formal setting, if we wish to reason about the contents of a linked list we would like to relate it to the abstract mathematical notion of sequences.

• •

Consider the following inductive definition of a predicate that describes the content of a linked list

[TABLE]

Here $\alpha$ denotes a mathematical sequence. Informally, the predicate $\textsf{listrep }\alpha\,\,(x,y)$ claims that $x$ points to a linked list segment ending at $y$ and the contents (head elements) of that segment are the sequence $\alpha$.

• •

While proving programs in this section we use $x\overset{\alpha}{\rightsquigarrow}y$ as an abbreviation for listrep $\alpha$  $(x,y)$ and $\alpha^{\dagger}$ to represent the reverse of the sequence $\alpha$.

Proof of In-place list reversal:

Consider the following piece of code, that performs an in-place reversal of a linked list:

[TABLE]

Here, $\boxtimes$ represents the null pointer. On a careful analysis of the code it is easy to see that,

• •

At any iteration of the while loop, variable $i$ and $j$ points to two different list segments having the contents $\alpha$ and $\beta$ such that concatenating $\beta$ at the end of $\alpha^{\dagger}$ will always result in $\alpha_{0}$.

• •

Thus, we have the following loop invariant

\exists\alpha,\beta.\texttt{ (i\overset{\alpha}{\rightsquigarrow}$$\boxtimes$\ * j$\overset{\beta}{\rightsquigarrow}\boxtimes$)$\wedge$\$\alpha_{0}^{\dagger}=\alpha^{\dagger}.\beta}

where, $\alpha_{0}$ represents the initial content of linked list pointed by variable $i$.

Also, note the use of separating conjunction in the loop invariant instead of the usual classical conjunction. If there is any sharing between the lists i and j then the program may malfunction. The use of a classical conjunction here cannot not guarantee such non-sharing.

It is easy to see how the postcondition of the list reversal program follows from the above loop invariant. Following sequence of specifications gives a derivation of the postcondition assuming the loop invariant and the termination condition $i=\boxtimes$,

[TABLE]

Where, the loop invariant can be verified using the following proof outline:

[TABLE]

Moreover, the following sequence of assertions gives a detailed proof of the implications $1\implies 2$ and $4\implies 5$:

[TABLE]

• •

Explanations:

• –

Most of the proof steps, specially those around a command, comprises of Hoare triples, which can easily be verified using the axioms for the corresponding commands.

• –

Note the use of $*$ instead of $\wedge$ in assertion 3. It insures that $i+1$ is different from $k$ and $j$. Hence an attempt to mutate the location $i+1$ does not affect the remaining two clauses $k\overset{\alpha^{\prime}}{\rightsquigarrow}\boxtimes\,\,$ and $\,\,j\overset{\beta}{\rightsquigarrow}\boxtimes$.

• –

We can obtain 1a from 1 by using definition of $i\overset{\alpha}{\rightsquigarrow}\boxtimes$ with the fact that $i\neq\boxtimes$. Then we unfold the definition of $i\overset{a.\alpha^{\prime}}{\rightsquigarrow}\boxtimes$ to obtain 1b from 1a. Finally instantiating $\exists a$ takes us to 2.

• –

4a is a simple rearrangement of 4. Since $i\overset{a.\beta}{\rightsquigarrow}\boxtimes$ is a shorthand for $i\mapsto a,j\,\,*\,\,j\overset{\beta}{\rightsquigarrow}\boxtimes$ we can obtain 4b from 4a. Finally we obtain 5 by generalizing $a.\beta$ in 4b as $\beta^{\prime}$ using the existential quantifier.

5 Conclusion

In this article we reviewed some of the important features of Separation Logic, that first appeared in [4, 5, 7]. The key idea of separating conjunction was inspired by the Burstall’s [2] “distinct non-repeating tree systems”. It is based on the idea of organizing assertions to localize the effect of a mutation. The separating conjunction gives us a succinct and more intuitive way to describe the memory disjointness, when pointers are involved. However, it is not the only possible way. One can see [8] for references and other works on proving pointer programs using the standard Hoare Logic.

In this paper we considered simple data structures to illustrate the power of Separation Logic. A more elaborate discussion with a variety of data structures can be found in [7, 9]. Reasoning becomes difficult when data structure uses more sharing. In this direction, one can refer Yang’s proof [11] of the Schorr- Waite graph marking algorithm.

We did not talk much about the proof theory behind Separation Logic. For a detailed discussion on the soundness and completeness results, one can refer [3, 6]. The soundness results for most of the derived rules, presented in this paper, can also be found in [9].

Finally, it should be noted that the goal here is not to identify a sound and complete logic for program verification. Instead, the challenge is to come up with a formalism that can capture the informal local reasoning used by programmers. Programmers often assume non sharing between data structures, which need explicit mention when using standard techniques, such as Hoare Logic. On the other hand, memory disjointness is default in the separating conjunction. Hence, separation logic gives us a more natural and concise way to model a programmer’s reasoning.