The Relationship Between Separation Logic and Implicit Dynamic Frames

Separation logic is a concise method for specifying programs that manipulate dynamically allocated storage. Partially inspired by separation logic, Implicit Dynamic Frames has recently been proposed, aiming at first-order tool support. In this paper, we precisely connect the semantics of these two logics. We define a logic whose syntax subsumes both that of a standard separation logic, and that of implicit dynamic frames as sub-syntaxes. We define a total heap semantics for our logic, and, for the separation logic subsyntax, prove it equivalent the standard partial heaps model. In order to define a semantics which works uniformly for both subsyntaxes, we define the novel concept of a minimal state extension, which provides a different (but equivalent) definition of the semantics of separation logic implication and magic wand connectives, while also giving a suitable semantics for these connectives in implicit dynamic frames. We show that our resulting semantics agrees with the existing definition of weakest pre-condition semantics for the implicit dynamic frames fragment. Finally, we show that we can encode the separation logic fragment of our logic into the implicit dynamic frames fragment, preserving semantics. For the connectives typically supported by tools, this shows that separation logic can be faithfully encoded in a first-order automatic verification tool (Chalice).


Introduction
Separation logic (SL) [5,11] is a popular approach to specifying the behaviour of programs, as it naturally deals with the issues of aliasing.Separation logic assertions extend classical logic with extra connectives and predicates to describe memory layout.This makes it difficult to reuse current tool support for verification.Implicit Dynamic Frames (IDF) [15] was developed to give the benefits of separation logic specifications while leveraging existing tool support for first-order logic.
Although IDF was partially inspired by separation logic, there are many differences between SL and IDF that make understanding their relationship difficult.SL does not allow expressions that refer to the heap, while IDF does.SL is defined on partial heaps, while IDF is defined using total heaps and permission masks.The semantics of IDF are only defined by its translation to first-order verification conditions, while SL has a direct Kripke semantics for its assertions.These differences make it challenging to understand the relationship between the two approaches.
In this paper, we develop an extended separation logic that both captures the original semantics of separation logic, and correctly captures the semantics of IDF.To achieve this we provide a separation logic based on total heaps and a permission mask.The permission mask specifies the locations in the heap which are safe to access.Our formulation allows expressions that access the heap to be defined, however it complicates the definition of the separation logic "magic wand" connective.In order to faithfully capture the original semantics of separation logic, and thus use magic wand to give the weakest pre-condition of commands, we present a non-standard definition of magic wand that includes changes to the total heap.
We also show that this extended separation logic correctly captures the semantics of the IDF formulas, we focus on the form of IDF found in the concurrent verification tool Chalice [9].As the semantics of IDF formulas are only defined indirectly via weakest pre-condition calculations for a language using them, we show that the verification conditions (VCs) generated by the existing Boogie2 [8] encoding and the VCs generated from the separation logic proof rules are logically equivalent.This shows that our model directly captures the semantics of IDF.
This strong correspondence enables us to encode a fragment of separation logic containing separating conjunction, points to assertions, equalities and conditionals on pure assertions (a typical fragment used in verification tools), into Chalice -a tool based on first-order theorem proving.
Outline The paper is structured as follows.We begin by presenting the background definitions of both separation logic and implicit dynamic frames ( §2); we then develop our extended separation logic ( §3).We prove the correspondence between VCs in the two approaches ( §4).Finally, we discuss related work ( §5) and consider possible extensions and conclude ( §6).
The contributions of this paper are as follows: -We define a total heap semantics for separation logic, and prove it equivalent with the standard (partial heaps) semantics for the logic.-We define a direct semantics for the implicit dynamic frames logic (the specification logic of the Chalice tool), which has so far only been given a semantics implicitly, via verification conditions.-We show how to encode a standard fragment of separation logic into an implicit dynamic frames setting, preserving its semantics.-We show that verification conditions as computed for separation logic coincide via our translation and semantics with the verification conditions computed by Chalice.

Standard Separation Logic
Separation logic [5,11] is a verification logic which was originally introduced to handle the verification of sequential programs in languages with manual memory management such as C. The key feature of the logic is the ability to describe the behaviour of commands in terms of disjoint heap fragments, greatly simplifying the work required when "framing on" extra properties in a modular setting.Since its inception, separation logic has evolved in a variety of ways.In particular, variants of separation logic are now used for the verification of object-oriented languages with garbage collection, such as Java and C ♯ [12].
In order to handle concurrency, separation logic has been extended to consider its basic points-to assertions as permissions [10], determining which thread is allowed to read and write the corresponding state.To gain flexibility, fractional permissions [4,3] were introduced, allowing the permissions governed by points-to assertions to be split and combined.A fractional permission is a rational number 0 < π ≤ 1, where 1 denotes full and exclusive (read/write) permission, and any other permission denotes read-only permission.In this paper we focus on the following core fragment of separation logic with fractional permissions.

Definition 1 (Separation Logic Assertions (SL)).
We assume a set of object identifiers3 , ranged over by ι.We also assume a set of field identifiers, ranged over by f .Values, ranged over by v are either object identifiers, integers, or the special value null.
The syntaxes of separation logic expressions (ranged over by e) and assertions (ranged over by a, b) are defined as follows 4 .In this definition, n ranges over integer constants, and We will refer to this separation logic simply as SL hereafter.
The key feature of separation logic is the facility to reason locally about separate heap portions.As such, the standard semantics for separation logic is formulated in terms of judgements parameterised by partial heaps (sometimes called heap fragments), which can be split and combined together as required.The critical new connectives are the separating conjunction * , and the magic wand − * .The separating conjunction a * b expresses that a and b are true and depend on disjoint fragments of the heap.The magic wand a − * b expresses that if any extra partial heap satisfying a is combined with the current partial heap, then the resulting heap is guaranteed to satisfy b.
Fractional permissions 5 are employed to manage shared memory concurrency in the usual way -a thread may only read from a heap location if it has a nonzero permission to the location, and it may only write to a location if it has the whole (full) permission to it.By careful permission accounting, it can then be guaranteed that a thread can never modify a heap location while another thread can read it.Note that permissions are handled (via points-to predicates e.f π ↦ e ′ ) on a per-field basis: it is possible for an assertion to provide permission for only one field of an object.This fine granularity of permissions allows for greater flexibility in the resulting logic -it can be specified that different threads have access to different fields of an object at the same time, for example.Combination of partial heaps includes combination of their permissions, where they overlap.

Definition 2 (Partial Fractional Heaps).
-A partial fractional heap h is a partial function from pairs (ι, f ) of objectidentifier and field-identifier to pairs (v, π) of value and non-zero permission π.Partial heap lookup is written h[ι, f ], and is only defined when -The combination of two partial heaps, written h 1 * h 2 , is defined only when h 1 ⊥ h 2 holds, by the following equations: We use ↓ n to denote the nth component of a tuple.
There are two main flavours of separation logic studied in the literature: classical separation logic, and intuitionistic separation logic.In this paper, we consider intuitionistic separation logic.In intuitionistic separation logic, truth of assertions is closed under heap extension, which is appropriate for a garbagecollected language such as Java/C ♯ , rather than a language with manual memory management, such as C. The standard intuitionistic separation logic semantics for our fragment SL is defined as follows.
The semantics for the separating conjunction and magic wand express the required splitting and combination of partial heaps.The semantics for logical implication → considers all possible extensions of the current heap, so that assertion truth is closed under heap extension [5].
Assume/Assert Verification in Boogie2 and related technologies uses two commands commonly to encode verification: assume A and assert A. The first allows the verification to work forwards with the additional assumption of A, while the second requires A to hold otherwise it will be considered a fault.These can be given weakest precondition semantics of: wp(assert A, B) = A ∧ B wp(assume A, B) = A ⇒ B From a verification perspective, these primitives can be used to encode many advanced language features.For example, in a modular verification setting with a first-order assertion language, a method-call is encoded by a sequence assert pre; havoc(Heap); assume post, in which pre and post are the pre-and post-conditions of the method respectively, and havoc(.) is a Boogie command that causes the prover to forget all knowledge about a variable/expression.
With separation logic, there are two forms of conjunction and implication, the standard (additive) ones ∧ and →, and the separating (multiplicative) ones * and − * .This naturally gives rise to a second form of assume and assert for the multiplicative connectives (assume * and assert * ), with the following weakest precondition semantics: wp(assert * A, B) = A * B wp(assume * A, B) = A − * B These commands can be understood as follows: assert * A removes a heap fragment satisfying A, and assume * A adds a heap fragment satisfying A. In a verification setting where assertions express permissions as well as functional properties, these can be used to correctly model the transfer of permissions when encoding various constructs.In a separation logic setting, a method call is encoded as assert * pre; assume * post.
In Chalice, which handles an assertion logic based on Implicit Dynamic Frames, functional verification is based on two new commands: inhale A and exhale A, which are also given an intuitive semantics of adding and removing access to state.One outcome of this paper is to make this intuitive connection between inhale/exhale and assume * /assert * formal, by defining a concrete and common semantics which can correctly characterise both assertion languages.

Chalice and Implicit Dynamic Frames
The original concept of Dynamic Frames comes from the PhD thesis of Kassios [7,6].The idea is to tackle the frame problem by allowing method specifications to declare the portion of the heap they may modify (a "frame" for the method call) via functions of the heap.The computed frames are therefore dynamic, in the sense that the actual values determined by these functions may change as the heap itself gets modified.Implicit Dynamic Frames [15,14] takes a different approach to computing frames -a first-order logic is extended with a new kind of assertion called an accessibility predicate (written e.g., as acc(x.f)) whose role is to represent a permission to a heap location x.f .In a method pre-condition, such an accessibility predicate indicates that the method requires permission to x.f in order to be called -usually because this location might be read or written to in the method implementation.By imposing the restriction that heap dereference expressions (whether in assertions or in method bodies) are only allowed if a corresponding permission has already been acquired, this specification style allows a method frame to be calculated implicitly from its pre-condition.
Chalice [9] is a tool written for the automatic verification of concurrent programs.It handles a fairly simple imperative language, with classes (but no inheritance), and several interesting concurrency features (locks, channels, fork/join of threads).The tool proves partial correctness of method specifications, as well as absence of deadlock.The core of the methodology is based on the Implicit Dynamic Frames specification logic, using accessibility predicates to handle the permissions necessary to avoid data races between threads.
In this paper we ignore the deadlock-avoidance aspects of Chalice, and focus on the aspects which guarantee functional correctness.Verification in Chalice is defined via an encoding into Boogie2, in which two auxiliary Chalice commands inhale p and exhale p are used.These commands reflect the addition and removal of permissions from the state, as well as expressing assumptions and assertions about the heap.For example, method calls are represented by exhale pre; inhale post.The command exhale pre has the effect of giving up any permissions mentioned in accessibility predicates in pre, and generating assert statements for any logical properties such as heap equalities.Dually, inhale post has the effect of adding any permissions mentioned in post and assuming any logical properties.

Definition 4 (Our Chalice Subsyntax). Expressions E and assertions p in our fragment of Chalice are given by the following syntax definitions:
Note that Chalice actually uses the symbol for logical conjunction (∧ or &&) where we write * above.However, in terms the semantics of the logic this is misleading -in general it is not the case that p ∧ p (as written in Chalice) is equivalent to p. Chalice's conjunction treats permissions multiplicatively, that is acc(x.f, 1) ∧ acc(x.f, 1) is actually equivalent to falsity.As we will show, Chalice conjunction is actually directly related to the separating conjunction of separation logic, hence our choice of notation here.Where we use the symbol ∧ later in the paper, we mean the usual (additive) conjunction, just as in SL.
Chalice performs verification condition generation via an encoding into Boo-gie2, which makes use of two special variables P and H.The former maps object identifier and field name pairs to permissions, in this instance a fractional permission, and is used for bookkeeping of permissions 7 .The latter maps object identifier and field name pairs to values, and is used to model the heap of the real program.These maps can be read from (e.g., P[o, f ]) and updated (e.g., P[o, f ] ∶= 1) from within the Boogie2 code, which allows Chalice to maintain their state appropriately to reflect the modifications made by the source program.In particular, the inhale and exhale commands have semantics which include modifications to the P map, to reflect the addition or removal of permissions by the program.
The critical aspect of Chalice's approach to data races, is to guarantee that assertions about the heap are only allowed when at least some permission is held to each heap location mentioned.This means that assertions cannot be made when it might be possible for other threads to be changing these locations -all logical properties used in the verification are then made robust to possible interference.Syntactically, this is enforced by requiring that assertions used in verification contracts are self-framing [6] -which means that the assertion includes enough accessibility predicates to "frame" its heap expressions.For example, the assertion x.f = 5 is not self-framing, since it refers to the heap location x.f without permission.On the other hand, (acc(x.f, 1) * x.f = 5) is self-framing.

A Total Heaps Semantics for Separation Logic
In this section we present a semantics for separation logic, which is based on states consisting of a total heap and a separate permission mask.Intuitively, the idea is that the permission mask specifies which locations in the heap we currently have permission to -this subset of the heap approximately corresponds with the partial heap which would be used in the standard semantics.The advantage of such a semantics is that it is simpler to relate to other logics with similar semantics and to encodings into first-order logic, as we will show later.
To facilitate comparisons, we define our semantics for an extended separation logic syntax, including not only the constructs of Definition 1, but also accessibility predicates from Implicit Dynamic Frames, and an enriched expression syntax that depend on the heap.

Definition 5 (Extended Separation Logic).
We define the expressions E and assertions A of extended separation logic (SL + ), by the following grammar (in which n stands for any integer constant): Note that the syntax of separation logic assertions (ranged over by a; see Definition 1) is a strict subset of the SL + assertions A defined above.The syntax of separation logic expressions e is also a strict subset of SL + expressions E.
Our aim is to give a total heap semantics for this more-general assertion language, implicitly defining a suitable semantics for both the fragment corresponding to SL assertions, and that corresponding to the assertions of Implicit Dynamic Frames.This semantics depends on states which are specified by a combination of a total heap and a permission mask which separately tracks permissions to heap locations.

Definition 6 (Total Heaps and Permission Masks).
A total heap H is a total map from pairs of object-identifier o and field-identifier f to values v. Heap lookup is written A permission mask Π is a total map from pairs of object-identifier and fieldidentifier to permissions.Permission lookup is written We write ∅ for the empty permission mask; i.e., the mask which assigns 0 to all locations.
Evaluation of extended separation logic expressions depends on a given environment and heap, and is defined by: The meaning of separation logic expressions is preserved (and is independent of the heap), as the following lemma shows: In order to define our semantics, we need to be able to combine permission masks:

Definition 7 (Combining Permission Masks). Two permission masks
The combination of two permission masks, written Π 1 * Π 2 is undefined if Π 1 and Π 2 are not compatible, and is otherwise defined pointwise to be the following permission mask: To define and prove results about our semantics, we need operations for replacing and removing portions of a heap, according to a specified permission.To this end, we introduce the following auxiliary definitions.

Definition 8 (Total Heap Operations).
Two heaps H 1 and H 2 agree on permissions Π, written H 1 Π ≡ H 2 , if the two heaps agree on all locations given non-zero permission by Π, i.e., The restriction of H to Π, written H↾Π is a partial fractional heap, defined by: The main difficulty in defining a semantics for SL using total heaps is getting the treatment of the magic wand connective correct.Since the standard semantics of this connective involves a quantification over all partial heaps which can be combined with the current one (i.e., all those which are compatible), it is not obvious how a corresponding definition can be made when starting from a total heap.The key idea is to model the "addition" of a new heap fragment which takes place in the standard semantics by acquiring some additional permissions, and then considering all possible heaps which have different values at the locations corresponding to these new permissions.In this way, the "newly acquired" region of our total heap can take on arbitrary new values.We model this by considering all heaps which agree with the current heap over the part to which any permission is held, and also satisfy the requirements of the "additional" heap.
Definition 9 (Total Heap Semantics for SL + ).We define validity of SL +assertions with respect to a specified total heap H and permission mask Π recursively on the structure of the assertion: Note the similarity between the definitions for magic wand − * and logical implication →. 8 This is because both cases involve heap extension in the partial heap semantics; in our total heap semantics we model heap extension by enabling the assignment of new arbitrary values to the part of the heap we have not yet acquired permission to.We observe that validity of assertions in this semantics is closed under permission extension.
Proof.By straightforward induction on the structure of the assertion A.
Semantically, an assertion is framed by a permission mask if it only depends on the values of heap locations which the permission mask assigns permission to.
An assertion is semantically self-framing if it is only true for permission masks large enough to frame it.These semantic notions of framing and self-framing are formalised as follows: Definition 10 (Framing, Self-Framing and Pure Assertions).A permission mask Π ′ frames an assertion A (Π ′ frames A) if and only if: For example, the assertion x.f = 5 is only framed by permission masks which give permission to location (x, f ).It is not self-framing, since with an environment σ such that σ(x) = ι, a heap H such that H[ι, f ] = 5 and an empty permission mask Π, we have H, Π, σ ⊧ SL + x.f = 5.However, the heap On the other hand, the assertions acc(x.f, 1) * x.f = 5 and x.f 1 ↦ 5 are both self-framing.Intuitively, self-framing assertions are robust to arbitrary interference on the rest of the heap.For separation logic assertions, this property holds naturally, since it is impossible for an assertion to talk about the heap without including the appropriate "points-to" predicates, which force the corresponding permissions to be held.

Lemma 2. All separation logic assertions a (Defn 1) are self-framing.
Proof.We prove, by straightforward induction on the structure of the assertion a, the equivalent statement: We now turn to relating our total heap semantics for separation logic, with the standard semantics.To do this, we need to relate partial heaps with pairs of total heap and permission mask.Given any total heap H and permission mask Π we can construct a corresponding partial heap H↾Π.Conversely, any partial heap h can be represented as the restriction of a total heap H to the permission mask corresponding to all the permissions in h.This representation however, is not unique -there are many such total heaps H we could choose such that h = H↾Π.However, the different choices of H can only differ over the locations given no permission in Π, and the previous lemma demonstrates that such differences do not affect the semantics of assertions.For our correspondence result, it is therefore without loss of generality to consider partial heaps constructed by H↾Π.We can then show that our total heap semantics for SL is sound and complete with respect to the standard semantics:
This result demonstrates that our total heap semantics correctly models the standard semantics of separation logic assertions.However, because our assertion language is more general than that of separation logic, not all properties of the separation logic connectives transfer across to the full generality of SL + .For example, in separation logic, the assertions a− * (b− * c) and (a * b)− * c are (always) equivalent.This is not quite the case in SL + .In order to precisely characterise the laws which hold, we require a notion of semantic entailment.We can now show how various laws which hold for separation logic transfer (in some cases partially) to our more general setting of SL + .

Proposition 2. For all SL
To see that the usual separation logic laws do not all hold in general, consider for example the two assertions The assertion P 2 is always true, essentially because no heap exists which satisfies (x.f = 1 * x.f = 2), and so the implication in the semantics of the wand holds vacuously.However, the assertion P 1 is not always true -if we consider the case where we do not have permission to x.f when checking the wand, we can pick two heaps which agree on our existing permissions and which assign x.f the values 1 and 2 respectively.However, 1 = 2 will of course be false in any configuration.
The usual separation logic laws do however hold for self-framing assertions (which by Lemma 2) includes all separation logic assertions).

Corollary 1. For all self-framing SL
To complete this section, we observe that we are able to eliminate the "pointsto" assertions from our syntax without loss of expressiveness.This is because of the following proposition: This result along with Theorem 1 shows that we can faithfully represent SL assertions in an implicit dynamic frames logic, in which permissions are tracked by accessibility predicates, and assertions about the heap are managed independently.Because our proofs are inductive on the structure of assertions, this representation result can also be applied to any fragments of SL.In particular, if we take the core fragment of SL typically supported by tools (in which assertions are built from separating conjunction and a restricted form of implication in which A → B is only allowed if A is permission-free), then we can faithfully encode this fragment into the logic of Chalice (Definition 4).
However, Chalice has its own semantics for this logic, which is implicitly defined via the weakest-precondition semantics for the language.Therefore, in order to provide a strong connection between standard separation logic and the Chalice methodology we must also show that our total heap semantics can be used to accurately reflect the semantics of Chalice.This is the focus of the next section.

Verification Conditions
In this section, we precisely connect the semantics of our assertion language with Chalice.Chalice does not provide a direct model for its assertion language.It instead defines the semantics of assertions using the weakest pre-condition semantics of the commands inhale and exhale.We show that this semantics precisely corresponds with the semantics in SL + .

Chalice
Chalice is defined by a translation into Boogie2 [8], which generates verification conditions on a many-sorted classical logic with first-order quantification.It has sorts for mathematical maps, which are used by Chalice to encode both the heap and the permission mask.We use ϕ to range over formulas in this logic, and σ ⊧ FO ϕ to mean ϕ holds in the standard semantics of first-order logic given the interpretation of free variables σ, and ⊧ FO ϕ means holds in all interpretations.
The definitions throughout this section generate expressions that have these two specific free variables: H for the current heap, and P for the current permission masks.Thus, H[x, f ] = 5 means in the current heap the variable x's field named f contains value 5.In the assertion logic, this corresponds to x.f = 5 where the heap access is implicit.
To enable us to relate the verification conditions in separation logic with those in Chalice, we need to be able to relate formulas in one approach with the other.We can provide a syntactic translation from the Chalice assertion logic into the first-order logic.Definition 12.We translate expressions that implicitly access the heap into expressions that explicitly access the heap as follows: and we translate formulas as follows: where [P 1 /P] means the replacement of P with P 1 , and P 1 * P 2 = P is a ternary predicate, true if and only if ∀i.P 1 (i) + P 2 (i) ≤ 1 ∧ P(i) = P 1 (i) + P 2 (i).
For example, the formula acc(x.f,π) * x.f = 5 will be translated to , that is the current heap contains 5 at x, f and the current permission mask has at least π permission on that location.
By interpreting the heap variable with concrete heap, and the permission mask variable with a concrete permission mask, we can show that the translated formula is true iff the original SL + formula was true.
where σ, H ↦ H, P ↦ Π is an interpretation that has all the mappings of σ and additionally maps the current heap, H, and permission mask, P, to the heap, H, and the permission mask, Π.
Chalice does not allow arbitrary formulas to be used as argument to inhale and exhale: it restricts the formulas to be self-framing.Chalice does not use the semantic check from earlier, but instead uses a syntactic formulation that checks self-framing from left-to-right.Note that this means that syntactic selfframing is not symmetric with respect to * .For instance, acc(x.f,π) * x.f = 5 is syntactically self-framing, but x.f = 5 * acc(x.f,π) is not.Somewhat surprisingly this is required by the way the verification conditions are generated.Definition 13.We define the footprint10 of a formula; an expression with the H variable free in it, that has the type of a set of locations and field name pairs.
We define a boolean expression syn framed ψ (E) to mean that all the fields mentioned in E are in the set ψ.
We lift this to formulas as Note that when we check that B is framed in A * B, we can use the footprint of A; these syntactic checks do not treat * as associative and commutative.
A formula, A, is syntactically self-framing, if it is framed by the empty set, syn framed ∅ (A).
We can now provide the definitions of the weakest pre-conditions of the commands for inhale and exhale.In Figure 1, we present the weakest pre-conditions of commands in Chalice from [9].We write wp ch (C, ϕ) for the weakest precondition of the command C given the post-condition ϕ.Chalice models the inhaling and exhaling of permission by mutating the permission mask variable.To exhale an equality (or any formula not mentioning the permission mask) we simply assert it must be true.This does not need to modify the permission mask.To exhale p * q, first we exhale p and then q.When an access predicate is exhaled, first we check that the permission mask contains sufficient permission, and then we remove the permission from the mask.
To inhale an equality, it is simply the same as assuming it.To inhale a p * q, we first inhale p and then q.There are two cases for inhaling a permission: (1) we don't currently have any permission to that location; and (2) we do currently have permission to that location.The first case proceeds by adding the permission, and then havocing the contents of that location, that is, making sure any previous value of the variable has been forgotten.The second case simply adds the permission to the permission mask. where

Relationship
In the rest of this section, we show that the verification conditions (VCs) generated by Chalice are equivalent to those generated by SL + .We focus on the inhale and exhale commands as these represent the semantics of the Chalice assertion language.By showing the equivalence, we show that our model of SL + is also a model for Chalice.
We write wp sl (C, A), to be the weakest pre-condition in SL + of the formula A with respect to the command C. We treat inhale and exhale as the multiplicative versions of assume and assert (see §2.1), and thus have the following weakest pre-conditions: Our core result is to show that both inhale and exhale have equivalent VCs in the two approaches.

Definition 14 (equiv(C)).
We define the VCs of a command as equivalent in both systems, equiv(C), iff for every self-framing SL + assertions, A, we have Our notion of equivalence of VCs only requires commands to have equivalent weakest pre-conditions for self-framing post-conditions, thus we need to show that each command preserves self-framing.If commands did not preserve self-framing, then sequencing could not be proved by induction on the subcommands.
Lemma 4. Each command preserves semantic self-framing: If A and p are selfframing, then so are wp sl (inhale p, A) and wp sl (exhale p, A).
The key to showing our semantics for SL + correctly embodies Chalice is to show that the VCs generated for the inhale and exhale commands are equivalent.The exhale is straightforward.The proof of inhale is more involved.This depends on the inhaled formula being syntactically self-framing.We must first prove a collection of lemmas to enable the proof to proceed by induction.(1) We need to connect the weakest precondition of an inhale with the footprint of a formula: that is, know that inhaling a formula adds its footprint to the permission mask.(2) The Chalice's VCs break inhale p * q into two inhales.This logically corresponds to currying/uncurrying a wand formula in SL + , but this is only true if the first formula is framed in the current world, so we need an analog of this for the VC world.Finally, (3) we need to know that introducing additional havocs to locations outside the current permission mask does not affect the weakest pre-condition assuming that the post-condition is framed by the current permission mask.Lemma 6.We want to show that if p is syntactically self-framing, then inhale p is equivalent in both approaches.However, we need to prove a stronger fact that accounts for the permissions we may have inhaled so far.In particular, as inhale p 1 * p 2 is implemented by first inhaling p 1 and then p 2 , when we consider inhaling p 2 it may not be self-framing.However, the context will have inhaled sufficient permissions that it is framed in that context.We prove that the VCs are equivalent in a context in which the inhale is framed.⇐⇒ wp ch (assume(ψ < P), wp sl (inhale p, A) )
The translation given by Smans et al. [15] does not suffer this problem as it does the analogue of inhale in a single step.However, it checks self-framing in a similar way, and thus would also rule out the first inhale.
In this section, we have shown that the encoding of inhale and exhale into Boogie2 is equivalent to the separation logic weakest pre-condition semantics.As a consequence, we have shown two things: (1) our model accurately reflects the semantics of Chalice's assertion language, and (2) a fragment of separation logic can be directly encoded into Chalice precisely preserving its semantics.

Related Work
In this paper, we have provided a version of separation logic [5,11], which allows arbitrary expressions over the heap.We have modified the standard presentation of an object-oriented heap for separation logic [12] to separate the notion of access from value.Most previous separation logics have combined these two concepts.One notable exception is the separation logic for reasoning about Cminor [1].This logic also separates the ability to access memory, the mask, from the actual contents of the heap.The choice in this work was to enable a reuse of a existing operational semantics for Cminor, rather than producing a new operational semantics involving partial states.In the Cminor separation logic, they do not consider the definition of magic wand, or weakest pre-condition semantics, which is crucial for the connection with Chalice [9].
Smans' original presentation of IDF was implemented in a tool, VeriCool [15,14].The results in this paper, should also apply to the verification conditions generated by VeriCool.In recent work, Smans et al. [16] describe an IDF approach as a separation logic.However, they do not present a model of the assertions, just the VCs of their analog of inhale and exhale.Hence, it does not provide the strong connection between the VCs and the model of separation logic that we have provided.
There have been many other approaches based on dynamic frames [6,7] to enable automated verification with standard verification tool chains, for instance, Dafny [13] and Region Logic [2].Like Chalice, both also encoded into Boogie2.The connection between these logics and separation logic is less clear.They explicitly talk about the footprint of an assertion, rather than implicitly.However, our new separation logic might facilitate greater comparison.

Extensions and Applications
In this section we highlight the potential impact of our connection between separation logic and the implicit dynamic frames of Chalice, by explaining several ways in which ideas from one world can be transferred to the other.

Supporting Extra Connectives
Our extended separation logic supports many more connectives than have previously existed in implicit dynamic frames logics.For example, the support for a "magic wand" in the logic (or indeed an unrestricted logical implication) is a novel contribution, which paves the way for investigating how to extend Chalice to support this much-richer assertion language.While a formal semantics for the magic wand does not immediately tell us how to implement inhaling and exhaling such assertions correctly, it provides us with a means of formally evaluating such a proposal.Furthermore, our direct semantics for the assertion logic of Chalice provides a means of judging whether a particular implementation is faithful to the intended logical semantics.
Evaluating the Chalice Implementation Various design decisions in the Chalice methodology can be evaluated using our formal semantics.For example, Chalice deals with potential interference from other threads by "havocing" heap locations whenever permission to the location is newly granted.An alternative design would be to "havoc" such locations whenever all permission to them was given up in an exhale, instead.This would provide different weakest preconditions for Chalice commands, and it would be interesting to investigate what differences this design decision makes from a theoretical perspective.Our results provide the necessary basis for such investigations.
Separation logics typically feature recursive (abstract) predicates in their assertion language.The Chalice tool also includes an experimental implementation of recursive predicates (without arguments), along with the use of "functions" in specifications to describe properties of the state in a way which could support information hiding.In the course of investigating how to extend our results to handle predicates in the assertion logics, we discovered that the current approach to handling predicates/functions in Chalice is actually unsound in the presence of functions and the decision to havoc on inhales rather than exhales.We, and the Chalice authors, are now working on a redesign of Chalice predicates based on our findings.As above, the formal semantics and connections we have provided give us excellent tools for evaluating such a redesign.
Implementing Separation Logic One exciting outcome of the results we have presented is that a certain fragment of separation logic specifications can be directly represented in implicit dynamic frames and automatically verified using the Chalice tool.This is a consequence of three results: 1. We have shown that our total heap semantics for separation logic coincides with its prior partial heaps semantics.2. We have shown that we can replace all "points-to" predicates with logical primitives from implicit dynamic frames, preserving semantics.3. We have shown that the Chalice weakest-pre-condition calculation agrees with the weakest pre-conditions used in separation logic verification.
The critical aspect which is missing is the treatment of predicates -once we can extend our correspondence results to handle recursively-defined predicates in the logics (which are used in virtually all separation logic verification examples), then it will be possible to exploit our work to use Chalice to implement separation logic verification.This will open up many interesting practical areas of work, in comparing the performance and encodings of verification problems between Chalice and separation logic based tools.

Old Expressions
We have also observed that the use of a total heap semantics seems to make it easy to support certain extra specification features in a separation logic assertion language.In particular, the use of "old" expressions in method contracts (allowing post-conditions to explicitly mention values of variables and heap locations in the pre-state of the method call) is awkward to support in a partial heaps semantics, since it expresses relationships between partial heap fragments which may not have obviously-related domains.As a consequence, separation logic based tools typically do not support this feature.However, with our total heap semantics it seems rather easy to evaluate old expressions by simply replacing our total heap with a copy of the pre-heap.While the details remain to be worked out, this seems to suggest that both separation logic and implicit dynamic frames can be made more expressive using the connections proved in our work.

A Some proofs (not in published version)
A.

Remark 1 .
Without the syntactic self-framing requirement on inhales, it would be unsound to break inhale A * B into inhale A; inhale B. In particular, in the Chalice semantics, the behaviour of inhale(A * B) and inhale(B * A) are different.For instance, consider inhale(x.f= 3 * acc(x.f)) and inhale(acc(x.f) * x.f = 3).