Verifying Executable Object-Oriented Specifications with Separation Logic Stephan van Staden, Cristiano Calcagno, Bertrand Meyer

Introduction Executable and separation logic specifications Examples: Executable specifications can be evaluated at runtime. Useful for debugging and testing. Lightweight Separation logic specifications are useful for verification 2

Executable specifications Verification questions: 1)Can we always execute them? Will their preconditions always be satisfied? Example: It does not make sense to talk about the first element of a newly created empty list 2)Will they always hold at runtime if executed? Example: A newly created empty list will not contain 10 elements 3)Will it matter if they are executed or not? Are they independent of the essence of the code? Complicated due to side-effects: modify object structures, nondeterministic, spawn threads, … Example: Does it matter if the postcondition of inserting an element checks whether it is in the list by allocating an iterator and affecting iterator bookkeeping? 3

Our contributions Allow both styles of specification. Reason about both using connecting implications, which answer all three questions posed before Reason about arbitrary side-effects in executable specifications with a new notion called relative purity 4

Existing approaches classify side-effects in executable specifications as intrinsically harmful or not If B is pure relative to P, then P is a footprint of B B can only perform side-effects permitted by P B must re-establish P, so it cannot “change things from the P point of view” Purity is in the eye of the asserter Relative purity 5

Examples x.f := e; False is pure relative to, but not pure relative to True insert(4); not is_empty is pure relative to, but not pure relative to 6

Given a sep logic predicate P and an executable assertion B which should hold at the same program point, does B somehow follow from P? Yes iff the connecting implication P B holds Lemma: If P B, then B is pure relative to P Precondition verification 7

Example For remove_first: Proof: 8

Postconditions may contain old-expressions: evaluated before the body is executed The connecting implication P,Q C means that any pre- state satisfying P and any post-state satisfying Q are sufficient to evaluate C to True: Let old(E1),…,old(En) be the old-expressions in B P,Q \ra B =def \exists R \cdot {P}(v1:=E1,…,vn:=En){P*R} and {Q*R}v:=B[v1;…;vn]{Q/\v=True} B[v1;…;vn] =def B[v1/old(E1),…,vn/old(En)] Postcondition verification 9

Example For remove_first: Proof: 10

Proof obligations summary 11

Implementation Reasoning support implemented in jStar Basic ingredients: symbolic execution, implication checking, frame inference Demonstration 12

Other work Class invariants Extracting predicates from executable specifications, i.e. work involving connecting implications of the form B P Connecting double implications of the form P B provide an integration of the two specification techniques 13

Related work Executable specifications Eiffel ESC Spec# JML: jmlc, JACK, LOOP Separation logic 14

In conclusion Give executable assertions a semantics based on their semantics as expressions Relative purity embraces side-effects in executable assertions Verification of executable specifications (i.e. answering the three questions) boils down to proving connecting implications The approach is general: also applicable to languages such as C 15

Thanks! Questions? 16