Object Invariants in Dynamic Contexts

Leino, K. Rustan M.; Müller, Péter

doi:10.1007/978-3-540-24851-4_22

Cited by 154 publications

(125 citation statements)

References 16 publications

Supporting

Mentioning

124

Contrasting

Order By: Relevance

“…Most of them employ the intermediate languages Boogie [18] or Why [10]. Chalice and VeriCool support implicit dynamic frames (in Chalice with fractional permissions), Dafny supports dynamic frames, and Spec# and VCC support ownership [19].…”

Section: Related Workmentioning

confidence: 99%

Comparing Verification Condition Generation with Symbolic Execution: An Experience Report

Kassios

Müller

Schwerhoff

2012

Verified Software: Theories, Tools, Experiments

Self Cite

View full text Add to dashboard Cite

Abstract. There are two dominant approaches for the construction of automatic program verifiers, Verification Condition Generation (VCG) and Symbolic Execution (SE). Both techniques have been used to develop powerful program verifiers. However, to the best of our knowledge, no systematic experiment has been conducted to compare them. This paper reports on such an experiment. We have used the specification and programming language Chalice and compared the performance of its standard VCG verifier with a newer SE engine called Syxc, using the Chalice test suite as a benchmark. We have focused on comparing the efficiency of the two approaches, choosing suitable metrics for that purpose. Our metrics also suggest conclusions about the predictability of the performance. Our results show that verification via SE is roughly twice as fast as via VCG. It requires only a small fraction of the quantifier instantiations that are performed in the VCG-based verification.

show abstract

Section: Related Workmentioning

confidence: 99%

Comparing Verification Condition Generation with Symbolic Execution: An Experience Report

Kassios

Müller

Schwerhoff

2012

Verified Software: Theories, Tools, Experiments

Self Cite

View full text Add to dashboard Cite

show abstract

“…The verifiers above that provide hiding enforce specific encapsulation disciplines through some combination of type checking and extra verification conditions. For example, the Boogie methodology [25] used by Spec# stipulates intermediate assertions (in all code) that guarantees an all-states ownership invariant. Another version of Spec# [38] generates verification conditions at intermediate steps to approximate read footprints, in addition to the usual end-to-end check that a method body satisfies its modifies specification.…”

Section: Related Workmentioning

confidence: 99%

“…A number of ownership disciplines from the literature are studied as instances of the framework. The framework encompasses variations on the idea that invariants hold exactly when control crosses module boundaries, e.g., visible state semantics requires all invariants to hold on all public method call/return boundaries; other proposals require invariants to hold more often [25] or less [39]. The difficulty of generalizing ownership to fit important design patterns led Parkinson and Bierman [5,32] to pursue abstraction instead of hiding, via second order assertions in separation logic; this has been implemented [10].…”

Section: Related Workmentioning

confidence: 99%

Dynamic Boundaries: Information Hiding by Second Order Framing with First Order Assertions

Naumann

Banerjee

2010

Programming Languages and Systems

View full text Add to dashboard Cite

Abstract. The hiding of internal invariants creates a mismatch between procedure specifications in an interface and proof obligations on the implementations of those procedures. The mismatch is sound if the invariants depend only on encapsulated state, but encapsulation is problematic in contemporary software due to the many uses of shared mutable objects. The mismatch is formalized here in a proof rule that achieves flexibility via explicit restrictions on client effects, expressed using ghost state and ordinary first order assertions.

show abstract

“…See our earlier work [18,26] for a discussion of invariants for aggregate objects. Moreover, we do not consider method calls in invariants.…”

Section: Object Invariantsmentioning

confidence: 99%

“…Spec# does not use a visible state semantics for invariants. Instead, invariants are checked at designated pack statements [18]. Since Spec# does not enforce Rule 6, client code has to be re-verified when an invariant is changed.…”

Section: Related Workmentioning

confidence: 99%

Information Hiding and Visibility in Interface Specifications

Leavens

Miiller

2007

29th International Conference on Software Engineering (ICSE'07)

View full text Add to dashboard Cite

Information hiding controls which parts of a class are visible to non-privileged and privileged clients (e.g., subclasses). This affects detailed design specifications in two ways. First, specifications should not expose hidden class members. As noted in previous work, this is important because such hidden members are not meaningful to all clients. But it also allows changes to hidden implementation details without invalidating correctness proofs for client code, which is important for maintaining verified programs. Second, to enable sound modular reasoning, certain specifications must be visible to clients. We present rules for information hiding in specifications for Java-like languages, and demonstrate their application to the specification language JML. These rules restrict proof obligations to only mention visible class members, but retain soundness. This allows maintenance of implementations and their specifications without affecting client reasoning. KeywordsInformation hiding, visibility, behavioral interface specification language, proof obligation, public, protected, private, client, JML language AbstractInformation hiding controls which parts of a class are visible to non-privileged and privileged clients (e.g., subclasses). This affects detailed design specifications in two ways. First, specifications should not expose hidden class members. As noted in previous work, this is important because such hidden members are not meaningful to all clients. But it also allows changes to hidden implementation details without invalidating correctness proofs for client code, which is important for maintaining verified programs. Second, to enable sound modular reasoning, certain specifications must be visible to clients. We present rules for information hiding in specifications for Java-like languages, and demonstrate their application to the specification language JML. These rules restrict proof obligations to only mention visible class members, but retain soundness. This allows maintenance of implementations and their specifications without affecting client reasoning.

show abstract

Object Invariants in Dynamic Contexts

Cited by 154 publications

References 16 publications

Comparing Verification Condition Generation with Symbolic Execution: An Experience Report

Comparing Verification Condition Generation with Symbolic Execution: An Experience Report

Dynamic Boundaries: Information Hiding by Second Order Framing with First Order Assertions

Information Hiding and Visibility in Interface Specifications

Contact Info

Product

Resources

About