Verifying Executable Object-Oriented Specifications with

Separation LogicStephan 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 BP,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

ExampleFor 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