verifying executable object-oriented specifications with separation logic
DESCRIPTION
Verifying Executable Object-Oriented Specifications with Separation Logic. Stephan van Staden , Cristiano Calcagno, Bertrand Meyer. Introduction. Executable and separation logic specifications Examples: - PowerPoint PPT PresentationTRANSCRIPT
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