Operational Semantics

This section defines the operational semantics of our programming language. Before doing that, we first define the semantic domains. Locations in our system correspond to object identifiers (which can be practically regarded as memory locations). Val- ues include primitive values, locations, and the special value null that does not correspond to any object identifier. Objects are finite partial maps that map field names to values. Primitive values include integer numbers and boolean values.

The operational semantics for our language is a small-step semantics which are essentially transitions between machine configurations. Each machine configuration is a triple consisting of:

• Heap h. We model heaps as finite partial maps from locations to objects.

Objects are expected to conform to their defined class types.

• Stack s. Stacks are modelled as finite partial maps from variables to values.

Note that it is viewed as a “stackable” mapping, where a variable v may occur several times, and s(v) always refers to the value of the variable v that was popped in most recently.1

• Current program code e. Program execution terminates when e is -, a value

of type void.

For simplicity, we assume that all while loops are already transformed to tail- recursive methods with pass-by-reference parameters. Each reduction step can then

1_{A more formal definition for s would mark different occurrences of the same variable with}

3.2. Separation Logic

be formalised as a small-step transition of the form:

hs, h, ei,→hs1, h1, e1i

The full set of transitions is given inFigure 3.2. We explain some of the notations used in them. The operation [v 7→ ν] + s “pushes” the variable v to s with the value ν, and ([v 7→ ν] + s)(v) = ν. The operation s − v “pops out” variables v from the stack s. s[v7→k] is a mapping which keeps all the mappings in s except that of v (which is now specified to be mapped to k). We also abuse this notation for a class type identifier c to denote a region of heap (mappings) in the form

c[f17→s(v1), . . . , fn7→s(vn)], which is essentially a heap location where fields fi are

further mapped to values s(vi), i = 1, . . . , n. ⊥ represents an arbitrary value. We

also introduce an intermediate construct as results returned by expressions/method calls ret(v, e), where v will be dropped from s after the evaluation/invocation of e, to simulate the behaviour of stack. Whenever such a result is yielded, we assume it is stored in a special logical variable res, although res is never explicitly put in the stack s.

3.2

Separation Logic

Our specification language is built on top of separation logic (O’Hearn and Pym,

1999;Reynolds,1999;Ishtiaq and O’Hearn,2001;Reynolds,2002), designed for rea- soning about programs that manipulate shared mutable pointer-based data struc- tures. The distinguished feature of separation logic is its local reasoning about data structures linked with pointers and allocated in heap (Distefano et al., 2006). It means that reasoning about a command concerns only the part of the heap that the command accesses, a.k.a. the command’s footprint. Note that local reasoning is not registered patent for separation logic; it also exists in the original formulation of Hoare logic (Hoare,1969) with the substitution treatment in assignment. However,

3.2. Separation Logic

OS-VAR hs, h, vi,→hs, h, s(v)i

OS-CONST hs, h, ki,→hs, h, ki

OS-SEQ hs, h, -; ei,→hs, h, ei

OS-ASSIGN-1 hs, h, v=ki,→hs[v7→k], h, -i OS-FIELD-READ hs, h, v.f i,→hs, h, h(s(v))(f )i

OS-LOCAL hs, h, {t v; e}i,→h[v7→⊥]+s, h, ret(v, e)i

OS-RET-1 hs, h, ret(v, k)i,→hs−{v}, h, ki

OS-PROG hs, h, e1i,→hs1, h1, e3i hs, h, e1; e2i,→hs1, h1, e3; e2i OS-ASSIGN-2 hs, h, ei,→hs1, h1, e1i hs, h, v=ei,→hs1, h1, v=e1i OS-RET-2 hs, h, ei,→hs1, h1, e1i

hs, h, ret(v, e)i,→hs1, h1, ret(v, e1)i

OS-FIELD-WRITE r = h(s(v1))[f 7→s(v2)] h1 = h[s(v1)7→r] hs, h, v1.f = v2i,→h(s, h1, -)i OS-IF-1 s(v)=true hs, h, if (v) e1 else e2i,→hs, h, e1i OS-IF-2 s(v)=false hs, h, if (v) e1 else e2i,→hs, h, e2i OS-NEW class c {t1 f1, .., tn fn} ι /∈dom(h) r=c[f17→s(v1), .., fn7→s(vn)] hs, h, new c(v)i,→hs, h[ι 7→ r], ιi

OS-CALL

s1=[wi7→s(vi)]m−1i=1 + s t0 mn((ti wi)i=1m−1; (ti wi)ni=m) {e}

hs, h, mn(v)i,→hs1, h, ret({wi}m−1i=1 , [vi/wi]ni=me)i

3.2. Separation Logic

such local reasoning is lost if heap-based data structure and aliasing are introduced to the programming language. This loss of locality is noted as the pointer swing problem by Hoare and He (1999). In this scenario, separation logic restores the capability to reason locally by means of two technical novelties: 1) the separation conjunction ∗ and 2) tight interpretation of Hoare triples (Yang and O’Hearn,2002). A key insight leading to separation logic is that program logics for reasoning about heap-manipulating programs should be explicit about the heap. In other words, program heaps should be part of the model of a program logic. The satisfiability of a separation logic formula ∆ in a program state is thus typically enforced by the semantics relation

s, h |= ∆

where s is a model of the program stack, h the program heap.

Some novel notations that separation logic has introduced include the points-to re- lationship 7→ and empty heap emp, and two new connectives (separation conjunction

∗ and spatial implication −∗). A points-to formula x 7→ y describes a singleton heap

with only one cell at address x that stores value y. Formula emp holds on empty heaps. Formula ∆1∗ ∆2 describes a heap that can be partitioned into two domain-

disjoint heaps described by ∆1 and ∆2. Formula ∆1−∗ ∆2 describes a heap that

if extended with a disjoint heap represented by ∆1, then ∆2 holds in the extended

heap. In other words, ∆1−∗ ∆2 captures the heap described by ∆2, where the heap

corresponding to ∆1 is “taken away”. The formal semantics of these operators will

be defined formally in Section 3.3.4.

Tight interpretation is another key aspect of separation logic, which ensures that “well-specified programs do not go wrong” (Reynolds, 2005). Under this interpre- tation, a valid Hoare triple {∆1} e {∆2} guarantees that command e should never

encounter a memory fault if started in a program state satisfying ∆1. One signifi-

3.2. Separation Logic

to guarantee that all memory locations accessed by the command, except for the freshly allocated ones, are allocated beforehand. In the setting of separation logic, a memory location x is considered allocated if the points-to fact x 7→ is present. More specifically, Hoare triples for heap-accessing commands in separation logic are as follows:

• Field read:

{x 7→ [v1, . . . , vi, . . . , vn]} x.fi {x 7→ [v1, . . . , vi, . . . , vn] ∧ res=vi}

where res is the special variable denoting the resulted value of an expression.

• Field write:

{x 7→ [v1, ..., vi−1, vi, vi+1, ..., vn]} x.fi=v {x 7→ [v1, ..., vi−1, v, vi+1, ..., vn]}

The above axioms illustrate the main characteristics of separation logic: in order to analyse a heap-accessing command, it must be explicitly proved that the heap location under consideration is allocated. Meanwhile, the reward is that any other heap locations can be ignored safely.

The interplay of separation conjunction and tight interpretation makes local reason- ing possible, which is formalised by the frame rule in separation logic:

{∆1} e {∆2}

{∆1∗ ∆3} e {∆2∗ ∆3}

mods(e) ∩ fv(∆3) = ∅

where mods(e) returns the set of variables modified by command e. Note that mods(e) includes neither modified fields, nor the variables used to reach these fields. fv(∆3) returns the set of free variables occurring in formula ∆3. The crucial power

of the frame rule is that it allows a global property to be derived from a local one, without necessity to look at other parts of the program.