Trace Properties from Separation Logic Specifications
Lars Birkedal, Thomas Dinsdale-Young, Guilhem Jaber, Kasper Svendsen,, Nikos Tzevelekos
TL;DR
This paper formalizes how separation logic specifications enforce trace properties on client-library interactions, ensuring protocol adherence through resource discipline and trace invariants.
Contribution
It introduces a formal framework connecting separation logic specifications with trace properties, using wrappers and extended logic to guarantee protocol enforcement.
Findings
Separation logic specifications enforce interaction protocols.
Wrapped library code maintains trace properties.
Correct client-library pairs satisfy trace invariants.
Abstract
We propose a formal approach for relating abstract separation logic library specifications with the trace properties they enforce on interactions between a client and a library. Separation logic with abstract predicates enforces a resource discipline that constrains when and how calls may be made between a client and a library. Intuitively, this can enforce a protocol on the interaction trace. This intuition is broadly used in the separation logic community but has not previously been formalised. We provide just such a formalisation. Our approach is based on using wrappers which instrument library code to induce execution traces for the properties under examination. By considering a separation logic extended with trace resources, we prove that when a library satisfies its separation logic specification then its wrapped version satisfies the same specification and, moreover, maintains…
Peer Reviews
No public reviews on file for this paper yet. If you reviewed it on a platform where reviews are public (OpenReview, ICLR, NeurIPS, ICML), you can paste yours below so the community can read it here.
Videos
No videos yet. Explain this paper in a talk, walkthrough, or lecture? Add one.
Taxonomy
TopicsDistributed systems and fault tolerance · Security and Verification in Computing · Logic, programming, and type systems
11institutetext: Aarhus University (11email: {birkedal,tyoung}@cs.au.dk) 22institutetext: University Paris Diderot (22email: [email protected]) 33institutetext: University of Cambridge (33email: [email protected]) 44institutetext: Queen Mary University of London (44email: [email protected])
Trace Properties from
Separation Logic Specifications
Lars Birkedal 11
Thomas Dinsdale-Young 11
Guilhem Jaber 22
Kasper Svendsen 33
Nikos Tzevelekos 44
Abstract
We propose a formal approach for relating abstract separation logic library specifications with the trace properties they enforce on interactions between a client and a library. Separation logic with abstract predicates enforces a resource discipline that constrains when and how calls may be made between a client and a library. Intuitively, this can enforce a protocol on the interaction trace. This intuition is broadly used in the separation logic community but has not previously been formalised. We provide just such a formalisation. Our approach is based on using wrappers which instrument library code to induce execution traces for the properties under examination. By considering a separation logic extended with trace resources, we prove that when a library satisfies its separation logic specification then its wrapped version satisfies the same specification and, moreover, maintains the trace properties as an invariant. Consequently, any client and library implementation that are correct with respect to the separation logic specification will satisfy the trace properties.
1 Introduction
Separation logic [24, 15] provides a powerful formalism for specifying an interface between a library and a client in terms of resources. For example, a client may obtain an “opened file” resource by calling an operation of a file library, which it can then use to access the file by calling a operation. Abstract predicates [23] crucially hide the implementation details — the client is not aware of what an “opened file” resource actually consists of, which may vary between implementations of the library, but only the functionality for using it that the library provides. A client that is verified with respect to the abstract specification will behave correctly with any implementation of the library.
In separation logic, functions are specified with preconditions and postconditions. We can think of the precondition as specifying resources that a client must provide in order to call the function. The postcondition then specifies the resources that the client receives when the function returns. For example, a simplified specification for a file library might be the following:
[TABLE]
A client acquires an open resource, represented by an abstract predicate, by calling open. With this file resource, the client can call close and relinquish the resource, or call read and retain the resource. The rules of separation logic allow us to prove specifications for clients that use the library correctly, such as:
[TABLE]
On the other hand, we cannot prove any useful specifications111It is always possible to prove a vacuous specification with precondition , but a useful specification should at least have a satisfiable precondition. For complete, closed programs we would typically expect the precondition to be . for programs that use the library incorrectly, like the following: .
Intuitively, separation logic specifications imply properties about the trace of interactions between a library and a client. For example, the specification for the file library ensures that a file can only be accessed if it has previously been opened and not subsequently closed. This strongly depends on the fact that the specification is abstract: a client has no way to obtain the open resource except by calling the operation. If the client were able to forge the open resource then it could violate the trace property. While this intuition is broadly used in the separation logic community, it has not previously been formalised.
In this paper we present a formal approach to establishing trace properties from abstract separation logic specifications. We achieve this by placing a wrapper between a client and a library that generates a trace of the interactions between the client and library. The wrapper has no bearing on the underlying semantics of the program (when traces are ignored) but simply allows us to formally interpret trace properties. Supposing that the library implements an abstract separation logic specification, we show that the wrapped library also satisfies this specification, but moreover maintains the desired trace properties as an invariant. For the latter step, we recur to a separation logic extended with trace resources, which can be used for instantiating the abstract predicates in the original specification. In the context of a client that uses the library in accordance with the specification, the trace properties are thus guaranteed to hold.
Our approach establishes temporal trace properties from separation logic specifications that are not inherently temporal, independently of implementation details. While ours is not the first approach incorporating temporal reasoning in program logics, and separation logic in particular (q.v. §7), it is the one to derive trace properties for libraries that already have separation logic specifications. Previous approaches [11, 9, 26, 25] achieve temporal reasoning by specifying and verifying the underlying libraries using trace-oriented specifications; the novelty of our work is in deriving temporal properties from trace-agnostic specifications.
A motivation for our approach is to justify separation logic specifications, by showing that they entail more intuitive trace properties. Such justification is particularly useful if the specification is intended to formally capture an English-language specification (e.g. the POSIX file system [10]). While we limit our presentation to the sequential setting and a simple higher-order separation logic, we can show trace properties that include elaborate protocols that are, for instance, parametric on object identifiers or beyond regular languages (q.v §5).
We begin by considering an illustrative example in §2. We introduce the programming language (§3) and our separation logic (§4) before we tackle examples in depth in §5. These examples establish that separation logic specifications can imply a variety of trace properties, such as:
- •
An iterator over a collection should only be used if the collection has not been modified since the iterator was created (§5.2).
- •
A higher-order function calls its argument exactly once (§5.3).
- •
A traversal on a stack invokes a given method on each value that has been pushed (but not popped) in the order in which they will be popped (§5.4).
- •
Any string received from the user should be sanitised before it is included in an SQL query (§0.A).
The semantics of the logic is presented in §6. Finally, we discuss conclusions and related work in §7.
2 Motivating Example
As a motivating example, consider a library that provides a stack with push and pop operations. In separation logic, these operations can be specified as follows:
[TABLE]
The push operation simply prepends the given value to the stack, which is represented by the abstract predicate. The value must be distinct from the unit , which is used to indicate an empty stack. The pop operation returns if the stack is empty, and otherwise removes and returns the head value.
We can also specify the stack in terms of trace properties that are satisfied by interactions between a client and a stack library. For instance, a simple trace property that we might wish to show is this:
Each (non-unit) value returned by an invocation of pop was an argument of a previous invocation of push.
In order capture trace properties, we define a wrapper that instruments the library operations with code to emit trace events as:
[TABLE]
We can then define a language of traces that captures our desired invariant:
[TABLE]
Our separation logic includes two resources that allow us to reason about code that emits trace events: expresses that is the current trace; and expresses that the trace invariant is . The proof rule for updates the resource, while requiring that the new trace satisfies the invariant. Using these, we can define a ‘wrapped’ version of the abstract predicate so that the wrapped operations will satisfy the same abstract specification, but also enforce the trace invariant:
[TABLE]
The proof of the wrapped push operation proceeds as follows:
push(v);
$\forall a\in(v::\alpha)\ldotp\exists i\ldotp(t\cdot\langle\texttt{push},v\rangle)[i]=\langle\texttt{push},a\rangle\}$
emitpush,v;
The wrapped pop operation can be verified similarly. We can thus conclude that the stack indeed satisfies the desired trace property.
The above example demonstrates our technique on a first-order library (the library cannot make call-backs to the client), but it also applies in a higher-order setting. For instance, consider extending the stack with a foreach operation that traverses the stack and calls a client-supplied function on each element in order. In separation logic, this operation can be specified as:
[TABLE]
This specification is subtle. The foreach operation takes a function that is specified (using a nested triple) with an invariant whose parameter records the list of values that has so far been called on. The operation is given the predicate initially, and it returns with , where is the reversal of the list . Note that while the predicate is abstract to the client (the library determines the interpretation), the predicate is abstract to the library (the client determines the interpretation). This means that for the library to obtain the predicate for the postcondition from the given in the precondition, it must call on each element of in order. Moreover, it cannot make any further calls to , since separation logic treats the predicate as a resource, which must be given up by the library each time it calls , and which the library has no means of duplicating since in separation logic does not hold in general.
Defining a wrapper for higher-order libraries is more complex than in the first-order case, since we wish the trace to capture all interactions between the client and the library, including call-backs between them. The wrapper must therefore emit events at the call and return of library functions, as well as functions that are passed as arguments to library functions. We can then specify a number of properties that traces generated by client-library interactions will have:
- •
The trace of push and pop operations obeys the stack discipline.
- •
Between invocation and return, calls on each element of the stack in order, with no further calls.
- •
The invocations of push, pop and (the argument of a call of foreach) are atomic — there are no further events between the call and return.
While the first property can be seen as a straightforward consequence of the push and pop specifications, the others are more subtle. In particular, they depend on the foreach specification’s parametricity in , which prevents the library from using its argument in an arbitrary fashion. For particular instantiations of , (e.g. ), foreach could call its argument an arbitrary number of times, or even store it and call it from future invocations of pop. However, parametricity ensures that it will behave the same independent of how is instantiated, and so it cannot do that since can be instantiated so as to enforce trace properties.
This example illustrates several important aspects of our approach. Firstly, we support higher-order functions, such as foreach. We also deal with expressive trace properties: the language of traces is not context-free, since the stack may be traversed multiple times. Moreover, the connection between the separation logic specification and the trace properties that follow from it is subtle.
In §5 we revisit this example, among others, in detail. Before doing so, we present the formal setting of our approach.
3 Programming Language
We define the programming language which will be the object of this study. To keep the setting general, the language is an untyped call-by-value -calculus with references, named functions, pairs, integers and primitives for arithmetic, reference usage and conditionals. Our language additionally features an primitive, which is used to output values as trace events. We will formulate properties in terms of the event traces produced by program evaluation. The syntactic classes of values (Val), expressions (Exp) and evaluation contexts (Con) are given respectively as follows.
[TABLE]
Above we let and , where Fun and Loc are countable sets of function and location identifiers respectively. Moreover, ranges over the set of variables Var, and ranges over a set of binary operators which includes equality test, assignment and arithmetic operators. We use Lam for the set of -abstraction expressions. Note that -abstractions are not values; functional values are represented by function identifiers.
Our operational semantics tracks -abstractions in an environment , where all encountered functions are named and stored. This allows us to track function usage by emitting trace events that refer to these function names. In addition, we can reduce expressions that use external functions: in such a case, an expression can contain the names of the external functions in its code, and would provide their bodies. The semantics draws from the open-term trace semantics used e.g. in [20], the main difference being that we explicitly control events generated by the reduction via the primitive (and also indiscriminately name -abstractions).
Expressions are evaluated inside states comprising a function environment and a heap . A heap is a finite map from locations to values and a function environment is a finite map from function identifiers to -abstractions. For any domain/codomain set pair , map and , we let regardless of whether or not. The evaluation rules are:
[TABLE]
The above defines a labelled transition system with labels from and, by taking its reflexive transitive closure (), we obtain labels from , which we shall call traces.
We next relate the behaviour of each expression with that of its counterpart where all emits have been omitted. We write for the expression obtained from by replacing all occurrences of by , and extend this notation to evaluation contexts and functional environments in the expected manner.
Theorem 3.1
For all , if then there exists a trace , an expression and an environment such that and .
This theorem justifies the fact that instrumenting terms with emits does not change their semantics. Its proof is in Appendix 0.C.
4 Logic
In this section we introduce our logic and prove some meta-theoretic results. The logic is a standard higher-order separation logic for the -calculus introduced in §3, extended with new primitives for reasoning about trace properties and programs that emit traces.
The logic consists of an assertion logic for reasoning about machine states and a specification logic for reasoning about the behaviour of programs. The assertion and specification logics are constructed over the same simply-typed term language. The types of this simply-typed term language are given below:
[TABLE]
The types include standard base types (unit, Booleans, and natural numbers) and type formers for functions, products and finite sequences. Additionally, there is a type for resource assertions (), a type for specifications (), and types for values, expressions and locations from the programming language (, and , respectively). The type is the type of finite sequences of elements of type ; we will use this type to represent traces.
The terms of the language are generated by the following grammar. The language includes a simply-typed -calculus with pairs, a higher-order logic with equality, primitive operators on finite sequences (), primitive separation logic resources (, , , ), Hoare triples and embeddings back and forth between the specification and assertion logic ( and ) and three trace primitives (, and ).
[TABLE]
The typing rules for the -calculus part are standard and have been omitted. Figure 1 includes an excerpt of some of the more interesting typing rules.
The typing judgement has the form where is a term context associating types with variables. Note that the typing rule for Hoare triples (THoare) takes an assertion as a precondition and a predicate as a postcondition to allow the postcondition to refer to the return value of the computation. Since we are reasoning about a -calculus (so that variables are immutable), we do not distinguish program and logical variables. The expression in a Hoare triple is thus typed in the same context as the Hoare triple, allowing us to refer to logical variables as program variables.
Judgements of the assertion logic have the form , where is again a term context, associating types to variables, is context of assumed specifications, and and are resource assertions. The judgement should be interpreted as: under the assumption the specifications hold, the resource assertion entails the resource assertion . The assertion logic consists of the usual entailment rules for higher-order separation logic [5] with the following additions,
[TABLE]
which allow us to use the specification context in propositional entailments.
Judgements of the specification logic have the form , where again and are term and specification contexts respectively, and is a specification The specification logic consists of the usual entailment rules for higher-order logic, with the addition of the rules in Figure 2. As a notational convention, we drop the in the postcondition: \left\{\begin{array}[]{@{}c@{}}P\end{array}\middle\}\ {e}\ \middle\{\begin{array}[]{@{}c@{}}r\ldotp Q\end{array}\right\} means \left\{\begin{array}[]{@{}c@{}}P\end{array}\middle\}\ {e}\ \middle\{\begin{array}[]{@{}c@{}}\lambda r:\mathsf{Val}\ldotp Q\end{array}\right\}, and \left\{\begin{array}[]{@{}c@{}}P\end{array}\middle\}\ {e}\ \middle\{\begin{array}[]{@{}c@{}}Q\end{array}\right\} stands for \left\{\begin{array}[]{@{}c@{}}P\end{array}\middle\}\ {e}\ \middle\{\begin{array}[]{@{}c@{}}\lambda\_:\mathsf{Val}\ldotp Q\end{array}\right\}.
Example 1
Consider the specification defined as follows:
[TABLE]
This specification describes a module which requires some initial resource to establish its invariant . The assertion permits the invariant to be constructed; since this is a resource assertion, it is wrapped in to produce the specification which asserts that the implication holds for all resources. The module provides one function, , that is specified by the Hoare triple. The specification states that, when is applied to a function that takes precondition to postcondition , then it will behave similarly in the presence of the invariant . The condition on the argument is specified with a nested triple in the precondition; since a triple is a and the precondition must be a , the triple must be wrapped by .
As a trivial implementation, we can prove . A client specification may be proved against an abstract module by proving:
[TABLE]
This can then be composed with the module implementation. ∎
Note that the specification logic lacks an application rule for applying an argument to a function. Instead, the abstraction rule returns a specification for the given function, applied to an arbitrary argument . To use this specification, we instantiate the specification with the actual function argument and pull out the nested triple to the context using the SpecOut rule.
Trace primitives.
The logic includes three basic assertions, , and , for reasoning about traces. The typing rules for these primitive trace assertions are given below. We use as shorthand for .
[TABLE]
The trace resource, , expresses that the trace of events emitted so far is exactly and asserts exclusive right to emit further trace events. The trace is represented as a finite sequence of values. Since asserts exclusive right to emit events, it cannot be duplicated. The resource thus allows a single owner to reason precisely about the current trace.
The resource suffices for examples where only a single resource needs to refer to the current trace. To improve expresiveness, we use the resource to reason about prefixes of the current trace. The resource asserts that the trace is a prefix of the trace of events emitted so far. Note that this property is preserved by emission of new events: if is a prefix of the current trace then is also a prefix of any extension of the current trace. This resource is duplicable, and given the resource we can construct a . Moreover, if we have a resource and a resource, we can conclude that is a prefix of . These properties are captured in the axioms PHistDupl, PAllocHist and PUseHist rules of the extended logic, given in Figure 2.
For several of our examples we require that all traces generated belong to a restricted language of traces. We express this formally using the invariant resource, , which defines a trace invariant that everyone must obey. Here is a set of traces and asserts that the current trace invariant is given by . Since it specifies an invariant, the resource is duplicable (axiom PInvDupl in Figure 2). A triple \left\{\begin{array}[]{@{}c@{}}P\end{array}\middle\}\ {e}\ \middle\{\begin{array}[]{@{}c@{}}Q\end{array}\right\} expresses that for every initial state satisfying if executes to a terminal state then the terminal state satisfies and the current trace at every intermediate state (including the initial and terminal state) satisfies the trace invariant.
To emit an event we thus require ownership of the trace resource and that the current trace after emitting the event satisfies the trace invariant . The proof rule Emit in Figure 2 captures this. Note that the assumption in the Emit rule is not strictly part of the syntax of our term language, but may be defined using fold. The same is true of and other operations on finite sequences, such as concatenation, length of a sequence and a subsequence operation. In subsequent sections we will use these definable operations without further mention. We will also occasionally need inductively defined predicates on traces. Since we are working in a higher-order logic, such predicates are definable within the logic using the usual impredicative Knaster-Tarski definition of least-fixed points of monotone operators.
5 Proving Trace Properties
In this section we show how to derive trace properties about client-library interactions from the library’s specification. We demonstrate our approach through a series of increasingly complex examples, starting with the basic file library example from the Introduction.
The basic idea is to prove that for any library implementation satisfying the abstract library specification, the wrapped library implementation satisfies the same abstract specification and moreover the traces generated by the wrapping satisfy a given invariant. This is achieved by reinterpreting the abstract representation predicates of the specifications to additionally relate the abstract state with the current trace using trace assertions. Client programs verified against the abstract library interface can thus be linked with the wrapped library implementation to conclude that the traces generated by the wrapping satisfy the given invariant.
Theorem 5.1 below formalises this idea. Here is an initialiser operation to initialize the internal state of the library. Theorem 5.1 allows us to prove that traces generated by running a client linked with a library implementation , after running the initialiser, belong to a given language .
Theorem 5.1
Given any specification , resource , initialiser , library implementation , machine states , trace , clients and language , if the following conditions hold then :
- •
* and *
- •
**
- •
**
- •
**
- •
**
Proof
Follows from soundness of the logic (Lemma 1 in §6). ∎
The above theorem requires that we provide a library implementation that satisfies the abstract specification and generates traces in the language . To use this theorem to derive a trace property from the separation logic specification,the idea is to define a suitable wrapper function for the library in questionand prove that if a library implementation satisfies then so does the wrappedversion and, additionally, the wrapped version generates traces in the language: .
5.1 File Library
To illustrate the idea, we begin by recalling the file library example from the Introduction. We prove that the associated separation logic specification enforces that clients verified against the specification only close and read when the file is open. To capture this property, we define a wrapper function that instruments an implementation of the file library to emit events about calls to open, close and read. Formally, we take a file library to be a triple consisting of an open, a close and a read function.
[TABLE]
We can now formalize the protocol as constraints on the traces generated by linking an instrumented file library with a client. In particular, we require that traces belong to the language of all strings such that is a valid file trace, , where and is defined as:
[TABLE]
The valid file trace predicate, , expresses that the trace only contains read and close events when the file is open. Recall the SL specification of the file library from the Introduction, here written more formally.
[TABLE]
To prove the specification enforces the intended protocol, we proceed by proving that the wrapping preserves satisfaction of the specification and generates traces in .
Lemma 1
.
Proof (sketch)
We first need to define new wrapped versions of the abstract representation predicates, which relate the abstract resources to the current trace. The idea is that the wrapped open resource, , should express that the current trace is in and that the trace is open. Likewise, the wrapped closed resource, should simply express that the current trace is in .
[TABLE]
We need to prove that assuming , which follows trivially from the definition of . It remains to prove that the wrapped methods satisfy their specifications. Below we give a proof outline for the wrapped open method.
open();
emit open;
Here we use the assumed specification of the underlying open method to verify the call to open and we used the following property of and to prove that emitting open would result in a trace in that was open.
[TABLE]
The proof outlines for the close and read operations are similar, but use the following property to justify the emits.
[TABLE]
5.2 Iterators on Collections
We consider a collections library that provides methods for modifying a collection as well as iterating over it. To ensure a well-defined semantics for iterators, we require the following property:
An iterator over a collection should only be used if the underlying collection has not been destructively modified since the iterator was created.
This is a trace property of the interaction between the collections library and clients. To capture it formally, we first define a suitable wrapper for the library that produces appropriate trace events. We take a collections library to be a tuple consisting of five operations: size, add, remove, iterator and next. The size operation is non-destructive and returns the size of the given collection. The add and remove operations destructively modify the given collection by adding or removing an element from the collection. Finally, iterator returns a new iterator for the collection, while next returns the next element of a given iterator.
The instrumentation is fairly straightforward and simply emits a suitable event indicating the operation called and the argument and/or return value of the given operation, when relevant:
[TABLE]
The traces ignore the arguments to add and remove and the return values of size and next, as they are irrelevant for the protocol.
With this instrumentation we can now express the informal protocol as a language of permissible interaction traces between the client and library. We let the trace alphabet be the countable set:
[TABLE]
The language of safe behaviours contains all strings such that, for all :
if then there is such that and, for all , .
That is, every call to the method of an iterator must be preceded by a call to which returns . In addition, there should be no modification of the collection between those two events.
To enforce this protocol we use a cut-down version of the iterator specification in [19] that does not track the contents of the underlying collections.
[TABLE]
The specification introduces two types of resources, coll and iter, to formally capture the protocol. The resource is indexed by an abstract version number while the resource expresses that is an iterator and the version number of the underlying collection was when the iterator was created. The operations that destructively update the collection consume a resource and produce a resource for an existentially quantified version number . As a result, after a destructive update, we should no longer be able to satisfy the precondition of next, as it requires ownership of a coll resource and an iter resource with a common version number .
To establish this intuition formally we prove that, for an arbitrary library implementation that satisfies the collections specification, the wrapped library implementation also satisfies the collections specification and the traces generated by the wrapped implementation are in the language .
Lemma 2
.
Proof (sketch)
To prove that the wrapped implementation satisfies the collections specification and produces traces in , we first need to define new wrapped versions of the coll and iter resources that relate the abstract version number to the trace state. The idea is that the collection parameter of the wrapped coll resource will consist of a pair , where the component is the parameter of the underlying coll resource and is the index in the trace of the last add or remove event. We want the wrapped resource to assert that there are no add or remove events in the current trace after the -th element. Likewise, the wrapped resource should assert that there is an iterator event for iterator in the current trace after the -th element. Hence, if we own both and then we know that no add or remove events were emitted since the iterator was created.
Let coll and iter denote the non-wrapped representation predicates that exist by the assumption and define the wrapped representation predicates and as follows:
[TABLE]
We use as notation for the subtrace of starting from the -th element.
It thus remains to show that the wrapped library satisfies the collections specification. First, we need to prove that we obtain a wrapped collection resource from the initial resources: . This follows easily from the assumption by taking the second component of to be 0.
Next, we have to show that each of the wrapped operations satisfies the corresponding Hoare specification. The size method is particularly simple, as any trace can trivially be extended with a size event . We will thus skip the size method. The add method is more interesting, as we have to update the index into the trace for the last add event. Below is a proof outline for the wrapped add method applied to argument z.
[Context ]
add(z);
emit add;
This leaves us with two proof obligations: firstly, we have to show that we are allowed to emit the add event (i.e., that ); and secondly for the last step we have to show that:
[TABLE]
This follows easily by taking to be , as contains no add or remove events after the -th element.
The proof for remove follows the same structure as for add. For the iterator method, we emit an iterator event and create a new resource to record the trace at the time of the creation of the iterator. Below we give a proof outline for the iterator method:
[Context ]
let r = iterator() in
emititerator, r;
r
As before, we are left with two proof obligations: and:
[TABLE]
To discharge this last proof obligation, we use the PAllocHist rule to introduce a history resource and since it follows that , as required by .
We are left with next, which is the most interesting case as it requires us to prove the iterator we are trying to use is still valid. We give a proof outline for the next method applied to an argument :
[Context ]
let r = next(x);
emitnext, x;
r
To verify the emit expression, we further have to prove that , that is, that the iterator x is still valid. This relies on the following key property of the language:
[TABLE]
To apply this property we use PUseHist to conclude from that and thus that .
5.3 Well-bracketing Protocols
Libraries that allow clients to acquire, access and release resources often impose a well-bracketing protocol whereby clients are required to acquire resources before accessing and releasing them. The file library in §5.1 was a particularly simple example of such a protocol. In this section we consider a more advanced and realistic variant thereof for a library with a higher-order function that takes care of acquiring and releasing the underlying resource for clients.
Consider a library with a higher-order method withRes for acquiring, accessing and subsequently releasing some resource (e.g. a file) and an operation op for accessing the resource. The withRes operation takes as argument a function provided by the client for accessing the resource and takes care of acquiring the resource before is called and subsequently releasing it again. For such a library, we wish to ensure that 1) clients only access the resource after they have acquired it, and 2) clients do not try to acquire resources they already hold.
To express this property formally, we first define a wrapping function that instruments the library to emit events about the interaction between client and library. Formally, we take a library implementation to be a tuple consisting of a withRes function and an operation op. Below we define a wrapping function for such a library that emits call and return events for all calls where control passes between client and library.
[TABLE]
We can now state the desired property as a well-bracketing property of the traces generated by the instrumented library. Let us define as the prefix closure of the language of all strings that are of the form:
[TABLE]
for some , and . That is, the strings in are well-bracketed sequences of events formed of subsequences adhering to the pattern , and subsequences thereof, where a sequence of consecutive calls and returns of .
This trace property is enforced by the following separation logic specification.
[TABLE]
This uses two abstract resources, unlocked and locked to capture the well-bracketing aspect of the protocol. In particular, calling withRes requires the client to relinquish ownership of the locked resource. Since the function provided by the client is only given ownership of the abstract unlocked resource, it cannot itself call withRes. Furthermore, to call op requires ownership of the unlocked resource, thus ensuring that only the callback provided by the client to withRes can call op. This specification ensures that withRes is forced to call the function provided by the client exactly once, as it is required to transform the abstract resource into and the only way it can achieve this is by calling the function provided by the client.
To prove that the specification enforces the trace property we proceed as usual, by proving that for any implementation that satisfies the specification, the wrapped implementation also satisfies the specification and the traces generated by the wrapped implementation are in .
Lemma 3
.
Proof (Proof sketch)
To prove that the wrapped version satisfies the specification and produces traces in , we first need to define wrapped versions of the abstract representation predicates. The idea is to let the wrapped locked resource, , express that the current trace is in and the and events in are well-balanced and well-bracketed. For the wrapped unlocked resource, , the idea is to use the argument to track the name of the last unbalanced event in .
To simplify the definitions and subsequent proofs, we first introduce a number of auxiliary resources, and . expresses that the current trace is well-balanced. We set . expresses that the current trace has the form where is well-balanced. expresses that the current trace has the form where is well-balanced and . Finally, expresses that the current trace has the form where is well-balanced and .
[TABLE]
[TABLE]
With these resources, we can now define and :
[TABLE]
It follows easily that from and the assumption .3
It remains to show that the two instrumented operations satisfy their specifications. We begin by showing that the instrumented withRes operation satisfies its specification:
[TABLE]
assuming withRes satisfies its specification:
[TABLE]
We give a proof outline for the instrumented withRes operation:
[Context ]
emitcall, withRes, f;
let g = x. emitcall, f; f(x); emitret, f in
withRes(g);
emitret, withRes, f
The interesting step is showing that from the assumed specification of we can derive the desired specification for the instrumented version of :
[TABLE]
This follows from the following proof outline
[Context and ]
emitcall, f;
f(x);
emitret, f
Lastly, we need to show that the instrumented op function satisfies its specification. Below we give a proof outline for the instrumented op function applied to an argument :
[Context ]
emitcall, op;
op(x);
emitret, op
where . ∎
5.4 Traversable stack example
To further demonstrate that our approach can express and enforce strong trace properties, recall the stack example from §2. We have a stack with a push and a pop method, and a foreach method that takes a function argument and applies the given function to every element of the stack, in order, starting from the top-most element. Here the protocol on the interaction between client and library imposes restrictions on both the client and the library. In particular, we wish to ensure that the function provided by the client cannot call back into the stack-library and potentially modify the underlying stack during the iteration of the stack. We also wish to ensure that the library calls the function provided by the client with every element currently on the stack and in the right order.
To express this protocol, we first define a suitable library wrapper that tracks all calls to push and pop and all calls to the function argument provided by the client when calling foreach.
[TABLE]
Let be the stack alphabet. We can formalize the intended protocol as the language defined as the prefix closure of the language of all traces such that holds, where, given , we define by:
[TABLE]
A higher-order separation logic specification for such a stack data structure is the following.
[TABLE]
It asserts existence of an abstract stack representation predicate that tracks the exact sequence of elements currently on the stack using the mathematical sequence . The specification for push and pop is straightforward: pushing and popping elements pushes or pops elements from this mathematical sequence, with a few special cases for pushing or popping from an empty stack. The specification for foreach is more interesting. It is parametrised by a predicate , to be chosen by the client. This predicate is indexed by a sequence and is intended to capture the client’s state after the function provided by the client has been called on each element of , in reverse order. This accounts for the in the post-condition, where is the reverse operator on sequences.
Lemma 4
.
Proof (Proof sketch)
We proceed by defining a wrapped version of the predicate that asserts that the sequence of elements matches the expected contents of the stack as per the current trace .
[TABLE]
Clearly we have that as and .
It remains to prove the wrapped library methods satisfy the specification instantiated with the wrapped predicate. The proofs for push and pop are straightforward and have been omitted. For foreach we are given a predicate from the client and need to prove the following triple:
[TABLE]
In the call to the underlying foreach method, we can pick a suitably wrapped version of the predicate, . The idea is that it should assert and that we have emitted an opening foreach call and called the function argument on all the elements of so far.
[TABLE]
We need to prove that the wrapped function argument updates the wrapped predicate appropriately. This follows from:
[Context ]
emit call, , a$$\rangle;
f(a);
emit ret, f$$\rangle;
The second to last step follows from the following property:
[TABLE]
Now the rest of the proof of foreach is just an application of the specification of the underlying foreach method and the Emit rule for the emission of the foreach call and return events.
6 Semantics
We give a denotational semantics for the logic introduced previously and establish soundness of the logic. The semantics is based on an interpretation of resources as members of a suitable resource monoid . In fact, is a partial commutative monoid whereby the multiplication operator acts as the semantic analogue of separating conjunction. We shall also use the partial order relation yielded by monoid multiplication: for all . In the sequel we shall frequently abuse notation and write simply as . The semantics of resources is parametrised on worlds, that is, partially ordered sets specifying functional environments and trace invariants.
The monoid models heap resources and trace resources. It is constructed as the product of two partial commutative monoids: , where:
[TABLE]
The monoid multiplication on Heap is disjoint union (), which is only defined between heaps with disjoint domains. The empty heap is the unit.
The monoid multiplication for the trace monoid is defined by:
[TABLE]
where is prefix ordering on finite sequences. The idea is that is modelled by , while is modelled by . The monoid multiplication ensures that is a unique resource, which grants the right to extend the trace. (It does not permit arbitrary changes to the trace: updates must preserve all frames, and hence all prefixes of the trace.) The resource is duplicable, and only ensures that is a prefix of the trace. It is easy to see that (where denotes the empty sequence) is the unit of this monoid.
Worlds model the information contained in assertions that does not behave like a resource. Worlds include the function environment and a trace invariant. We thus define with iff and The ordering on worlds describes how they may change with time. This ordering allows new functions to be named, but enforces that the trace invariant does not change with time.
Assertions are interpreted as monotone functions from worlds to upwards closed sets of resources: where . The rest of the types are interpreted as shown below, where the ordering on is .
[TABLE]
The semantics of a term is defined inductively as in Figure 3. (We give selected cases; for full details see Appendix 0.B.) The semantics is defined in terms of a variable environment that maps variables of type to elements of :
The definition of the weakest precondition , used to define the semantics of Hoare triples, enforces the invariant on traces generated by the considered terms. It is defined as a greatest fixed-point, which establishes that the updates to the concrete state (the trace , heap , and function context ) simulate updates to the abstract state (the resource and world ), with respect to the erasure relation (). Updates to the concrete state are according to the operational semantics, while updates to the abstract state must preserve frames () and increase the world. When a terminal configuration is reached, the abstract state must satisfy the postcondition.
The semantics of entailment in the logic is defined as:
[TABLE]
where (here is lub in ).
Soundness of the logic is proved by induction on the structure of derivations (cf. Appendix 0.B). Using soundness, we can relate a proof of a triple \left\{\begin{array}[]{@{}c@{}}P\end{array}\middle\}\ {e}\ \middle\{\begin{array}[]{@{}c@{}}Q\end{array}\right\} to the store and trace obtained from the reduction of .
Theorem 6.1 (Soundness)
If then .
Corollary 1
Suppose \Gamma\mid-\vdash\left\{\begin{array}[]{@{}c@{}}P\end{array}\middle\}\ {e}\ \middle\{\begin{array}[]{@{}c@{}}Q\end{array}\right\} and let and . Then, for all such that and , for some , we have that and .
7 Conclusions
In this paper we demonstrated a formal approach for relating library specifications, expressed in separation logic, with the trace properties they enforce on the interaction between clients verified against the specified library and the library itself. The distinctive strength of our technique is that it is based purely on the abstract library specification and is independent of both client and library implementations. As such, it differs from the standard verification approach where one verifies a program against a given specification expressing the desired property. Since our main goal has been to establish a theoretical foundation relating specifications and trace properties, we focused on expressiveness rather than automation.
7.1 Related Work
Several lines of work have targeted static verification of safety trace properties of object-oriented and higher-order programs.
A particularly influential approach has been Typestates [29, 8]. These can be seen as specifying trace properties using pre/post-conditions. They have been used to check safety temporal properties of programs, by associating abstract states to objects, then specifying which methods can be called at each state and how they make the state evolve. In [3, 4] they are combined with aliasing information to give a sound and modular analysis of API usage protocols, and to check a specification for the iterator module similar to ours, yet based on a single object. Multi-object properties, like the iterator one, can be captured by an extension of typestates using tracematches to specify intensional properties [22].
Static analyses based on type systems have been widely used to check resource usage, like our file module example. Linear types are used in [7] to develop Vault, a programming language used to design device drivers, where resource management protocols can be specified explicitly using annotations in the source code. An automatic analysis has then been developed in [14].
Type and effect systems have been used in [28] to infer resource usage, represented by an LTS, and combined with model checking to verify trace properties of programs. Such systems have been applied to Featherweight Java in [27], where challenges coming from object orientation like inheritance and dynamic dispatch are tackled.
Higher-order model checking has been used to provide a sound and complete resource usage analysis, using higher-order recursion scheme model checking for a fragment of the -calculus [18].
Those approaches have been designed to support automated static verification and thus trade off expressiveness for automation. Here we have made the opposite trade-off and focused on being able to capture expressive trace properties. As seen, we can specify non-regular properties (5.3, the language is visibly pushdown [1]), others that rely on tracking an unbounded number of objects (5.2 and Appendix 0.A, where we need to track all valid iterators and strings respectively), and we can even go beyond context-free languages (5.4, the language requires an order-2 pushdown automaton [21]). On an orthogonal direction, working with a logic with quantification we can specify traces from infinite alphabets of trace events (5.2, 5.3, 5.4 and Appendix 0.A).
Our key contribution is a technique for formally relating separation logic specifications with the temporal properties they enforce, through wrapping abstract resources with assertions about traces. On the other hand, a very active line of work has targeted the verification of fine-grained concurrent data structures using program logics with histories [11, 9] and separation logics [26, 25]. Fine-grained concurrent algorithms use locking at the level of individual memory operations and their correctness often relies on subtle temporal properties about internal interactions within libraries. These approaches include primitives for reasoning explicitly about traces [11, 9] or assign to (fine-grained) separation logic primitives history-oriented interpretations [26]. Temporal reasoning is thus achieved in a different way than herein, namely by specifying and verifying the underlying libraries themselves, whereas we derive temporal properties from specifications that are not themselves temporal.
The F7 and F*∗* programming languages provide another technique for reasoning about trace properties [30, 2]. The technique is primarily aimed at verifying cryptographic primitives, but has also been applied to access control policies about interactions between a client and resources managed through libraries [6]. It is based on extending the base programming language with a primitive for assuming that a given formula holds and an assert primitive that fails if a given formula does not follow from all previously assumed formulas. Access control policies are encoded by inserting appropriate assume and assert statements and proving that no assert can fail. In comparison to our work, the approach does not establish a formal connection between the inserted assume/assert statements and the property enforced on the execution. It is also non-local in that any assume statement can introduce a contradiction and break adequacy.
7.2 Further Directions
We demonstrated the power of even a basic higher-order separation logic for enforcing elaborate trace properties. A more expressive logic with better support for shared-resource reasoning would allow us to enforce even more elaborate protocols. In the future we therefore intend to apply our technique to a fully featured concurrent higher-order separation logic [17].
In the concurrent setting, linearisability [13] is a trace property that is commonly used to specify that operations of a library behave as if they were atomic. Several concurrent separation logics adopt a different approach to specifying atomicity, due to Jacobs and Piessens [16]. Although there is a strong intuitive argument that this approach implies linearisability, a formal connection has not been made. Our technique could be used to formalise such a connection.
Another direction concerns the description of the captured protocols via formal language tools, such as automata. Note that such a step is not to be taken lightly, as one would need to establish a formal link between the description and the logical specification. A related area for future work would be a formal (and, ideally, automated) procedure for deriving separation logic specifications for enforcing a given protocol from a formal definition of the protocol.
Appendix 0.A String Sanitisation
Another interesting example is string sanitisation [12]. Suppose strings are fetched from a web form, processed internally and passed as part of an SQL query to a database server. To avoid injection attacks, all inputs from the web form should be sanitized before being passed to the database server. We can express this as a taint protocol. Strings received from the user are considered tainted initially. Taint remains with a string and is also passed to any string produced by processing some tainted string. The only way to remove taint from a string is by sanitising it. A protocol we may require is:
No tainted string can reach the database server.
To express this trace property formally, we first define a suitable wrapping around a string library, that emits events describing the interaction between library and client. Suppose that a string library consists of five methods: an input method for obtaining strings from the user via a web form, a constant method for declaring string constants in the code, a sanitize method, a concatenation method, concat, and a sink method, sink, for sending a given string to the database server. Formally, we represent the library as a 5-tuple of these operations. We can now define a wrapper that takes a string library and returns an instrumented string library. The instrumentation is fairly straightforward and simply emits a suitable event indicating the operation called and the argument and/or return value of the given operation, when relevant:
[TABLE]
We can now define the trace property as a constraint on the traces generated by linking a client with an instrumented library. We let the alphabet be the following countable set:
[TABLE]
Intuitively, we want to constrain traces such that for any event in the trace, all the strings used to construct are safe to emit, meaning that the trace contains a corresponding constant event or sanitize event for such . We first define, by induction on , a predicate to express that the string is safe to emit given that the current trace is . We let and:
[TABLE]
Note such inductive predicates are definable in higher-order logic.
We wish to ensure that once a string has been sanitised it can never become tainted again or, stated in terms of esafe, once a string is safe for then it is also safe for all future histories such that . To ensure this we require the library to ensure that input, constant and concat always return fresh string pointers that have never been used before. We thus define the language of valid traces, , as the set of all strings such that , where:
[TABLE]
The predicate expresses that either every sink event in uses a safe string or the library does not ensure sufficient freshness of string pointers. In the latter case we do not constrain the client at all. We thus have the following crucial property, which ensures that if a string is safe for the current trace then it is also safe for any future trace with sufficiently fresh string pointers:
[TABLE]
Below we define a separation logic specification for the string sanitisation library that ensures clients only call sink with safe strings. The specification uses a resource R for the local state of the sanitisation library, a string resource for each string and a safe resource which expresses that the string is safe. As expected, sanitize turns a string into a safe string and concat applied to safe strings yields a safe string.
[TABLE]
As usual, we proceed by proving that the instrumentation preserves the library specification and generates traces in .
Lemma 5
.
Proof (Proof sketch)
To prove that the instrumentation preserves the library specification we first have to define instrumented versions of the abstract representation predicates. We let the local state resource take ownership of the resource and let assert the existence of some trace prefix in which the given string is safe or for which the library failed to ensure sufficiently fresh string pointers:
[TABLE]
It remains to show that the instrumentation preserves the specifications of each of the library methods. The most interesting cases are sink, and concat when on two safe strings. For the latter we have:
[Context ]
let = concat(, ) in
emitconcat, , , s_{2}$$\rangle;
here we use the following properties of esafe to verify the emit:
[TABLE]
For the sink case, we have:
[Context ]
sink();
emitsink, s$$\rangle;
Appendix 0.B Soundness
The semantics of all terms is given in Figure 4.
Theorem 6.1 (Soundess)
If then .
Soundness is established by showing that each of the proof rules is semantically valid.
As a notational convenience, given we write just if . We moreover define as , and extend this notation to arbitrary unions for .
Moreover, for each , we let stand for ; whereby, for each , .
Lemma 6 (Hyp rule)
[TABLE]
Proof
Let . Since , we have by definition.
Lemma 7 (Ret rule)
[TABLE]
Proof
Let and .
[TABLE]
Hence \Gamma\mid\Theta\models\left\{\begin{array}[]{@{}c@{}}\top\end{array}\middle\}\ {v}\ \middle\{\begin{array}[]{@{}c@{}}r\ldotp r=v\end{array}\right\}.
Lemma 8 (Monotonicity of )
For all and , if then .
Proof
Straightforward, by co-induction.
Lemma 9
For all , , evaluation contexts , and ,
[TABLE]
where .
Proof
By co-induction. Assume and that are such that . If then and thus and as required, using continuity of . Suppose that . If then, as above, . Otherwise, there exists such that and . It then follows from the assumption that there exist and with and . By the co-inductive assumption, and so as required.
Corollary 2 (Bind rule)
If
[TABLE]
where , then
[TABLE]
Proof
Corollary 3 (Csq rule)
If
[TABLE]
then
[TABLE]
Proof
Let and be such that . Suppose that . By the first assumption, it follows that . By the second assumption, it follows that . By the third assumption, we have . By Lemma 8, it then follows that , as required.
Lemma 10 (Framing)
For all , , and ,
[TABLE]
Proof
By co-induction. It suffices to show that, for all , where is such that (as implied in the definition of ). Take any , , with . Then there exist such that , and . If then, since , it follows that and ; we can hence conclude that . If then since , it follows that there are and there exists such that and ; hence and we thus have that , as required.
Corollary 4 (Frame rule)
If \Gamma\mid\Theta\models\left\{\begin{array}[]{@{}c@{}}P\end{array}\middle\}\ {e}\ \middle\{\begin{array}[]{@{}c@{}}Q\end{array}\right\} then \Gamma\mid\Theta\models\left\{\begin{array}[]{@{}c@{}}P*R\end{array}\middle\}\ {e}\ \middle\{\begin{array}[]{@{}c@{}}\lambda r\ldotp Q(r)*R\end{array}\right\}.
Proof
Let and be such that . By assumption,
[TABLE]
It follows by monotonicity of and Lemma 10 that
[TABLE]
as required.
Lemma 11 (Abs rule)
If
[TABLE]
where , then
[TABLE]
Proof
Let and be such that . Let . Suppose that and . Then it must be that , , and . Let , so and . Moreover, by monotonicity. By assumption, we have, for all , [\![\Gamma,x:\mathsf{Val}\vdash\left\{\begin{array}[]{@{}c@{}}P\end{array}\middle\}\ {e}\ \middle\{\begin{array}[]{@{}c@{}}Q\end{array}\right\}]\!]_{\rho{[x\mapsto v]}}(w^{\prime}). Consequently,
[TABLE]
and so \Gamma\mid\Theta\models\left\{\begin{array}[]{@{}c@{}}\mathsf{emp}\end{array}\middle\}\ {\lambda x\ldotp e}\ \middle\{\begin{array}[]{@{}c@{}}r\ldotp\forall x:\mathsf{Val}\ldotp\mathsf{spec}(\left\{\begin{array}[]{@{}c@{}}P\end{array}\middle\}\ {rx}\ \middle\{\begin{array}[]{@{}c@{}}Q\end{array}\right\})\end{array}\right\} as required.
Lemma 12 (SpecOut rule)
If
[TABLE]
then
[TABLE]
Proof
Let and be such that . Let . Then and . Hence , and thus by assumption
[TABLE]
It follows that , as required.
Lemma 13 (Alloc rule)
[TABLE]
Proof
Let and be such that . Let . Suppose that and . Then it must be that , , and . Consequently, . Now
[TABLE]
as required.
Lemma 14 (Read rule)
[TABLE]
Proof
Let and be such that . Let . Suppose that and . (Note that since , we do not have .) It must be that , , and . Now
[TABLE]
as required.
Lemma 15 (Write rule)
[TABLE]
Proof
Let and be such that . Let . Suppose that and . (Note that since for some , we do not have .) It must be that , , and . Let , so that Now
[TABLE]
as required.
Lemma 16 (Emit rule)
Let . If
[TABLE]
then
[TABLE]
Proof
Let and be such that . Let . Suppose that . It follows that and, by the assumption, . Suppose also that . (Note that we do not have .) It must be that , and . Let . It must also be that . Now
[TABLE]
as required.
Lemma 17
Suppose that \Gamma\mid-\vdash\left\{\begin{array}[]{@{}c@{}}P\end{array}\middle\}\ {e}\ \middle\{\begin{array}[]{@{}c@{}}Q\end{array}\right\} and let and . Taking such that , suppose that there exists with . Then and there exists and such that .
Proof
From Theorem 6.1, we get that \Gamma\mid-\models\left\{\begin{array}[]{@{}c@{}}P\end{array}\middle\}\ {e}\ \middle\{\begin{array}[]{@{}c@{}}Q\end{array}\right\}, i.e. \forall w\in{\mathsf{W}}.\forall\rho\in[\![\Gamma]\!].[\![\Gamma\vdash\left\{\begin{array}[]{@{}c@{}}P\end{array}\middle\}\ {e}\ \middle\{\begin{array}[]{@{}c@{}}Q\end{array}\right\}:\mathsf{Spec}]\!]_{\rho}(w)=\top. Thus, we get that . So taking such that and , we know that .
Writing for , from
- •
- •
- •
we prove by induction on the length of this reduction above that and there exists and such that .
For the base case, , and . Unfolding the definition of wp, since it follows that and that , so that we take and .
For the inductive case, assume . Unfolding the definition of wp, it follows that there exists and such that
[TABLE]
By the induction hypothesis, it follows that there exists and such that .
Appendix 0.C Erasure of instrumentation
Lemma 18
For all , if (without emitting any events) then .
Proof
By case analysis on the reduction step, using the fact that .
Theorem 3.1
For all , if then there exists a trace , an expression and an environment such that and .
Proof
By induction on the (lexicographic order of the) length of the reduction of and the number of s in . If is irreducible, then either:
- •
is irreducible, so that we can define as the empty trace, as and as .
- •
or so that . Then we can apply the induction hypothesis since has strictly fewer s than , and .
Otherwise, there exist such that . There are two possibilities:
- •
Either there exist , such that without emitting any events, in which case, from the previous lemma and the determinism of the reduction, we get that and . We now use the IH to prove the claim.
- •
Or so that . Then we can apply the IH since has strictly fewer s than , and .
The reference list from the paper itself. Each links out to its DOI / PubMed record.
- 1[1] Alur, R., Madhusudan, P.: Visibly pushdown languages. In: Proceedings of the 36th Annual ACM Symposium on Theory of Computing, Chicago, IL, USA, June 13-16, 2004. pp. 202–211 (2004)
- 2[2] Bengtson, J., Bhargavan, K., Fournet, C., Gordon, A.D., Maffeis, S.: Refinement Types for Secure Implementations. ACM Trans. Program. Lang. Syst. 33(2), 8:1–8:45 (Feb 2011)
- 3[3] Bierhoff, K., Aldrich, J.: Modular typestate checking of aliased objects. In: Proceedings of the 22nd Annual ACM SIGPLAN Conference on Object-oriented Programming Systems and Applications. pp. 301–320. OOPSLA’07, ACM (2007)
- 4[4] Bierhoff, K., Beckman, N.E., Aldrich, J.: Practical API protocol checking with access permissions. In: Proceedings of the 23rd European Conference on Object-Oriented Programming. pp. 195–219. ECOOP’09, Springer-Verlag (2009)
- 5[5] Biering, B., Birkedal, L., Torp-Smith, N.: Bi-hyperdoctrines, higher-order separation logic, and abstraction. ACM Trans. Program. Lang. Syst. 29(5) (Aug 2007)
- 6[6] Borgström, J., Gordon, A.D., Pucella, R.: Roles, Stacks, Histories: A Triple for Hoare. Journal of Functional Programming 21, 159–207 (2011)
- 7[7] De Line, R., Fähndrich, M.: Enforcing high-level protocols in low-level software. In: Proceedings of the ACM SIGPLAN 2001 Conference on Programming Language Design and Implementation. pp. 59–69. PLDI ’01, ACM (2001)
- 8[8] De Line, R., Fähndrich, M.: Typestates for objects. In: Object-Oriented Programming: Proceedings of the 18th European Conference on Object-Oriented Programming. p. 465. ECOOP’04, Springer-Verlag (2004)