Proving Consistency of Pure Methods and Model Fields

Abstract

Pure methods and model fields are useful and common specification constructs that can be interpreted by the introduction of axioms in a program verifier's underlying proof system. Care has to be taken that these axioms do not introduce an inconsistency into the proof system. This paper describes and proves sound an approach that ensures no inconsistencies are introduced. Unlike some previous syntax-based approaches, this approach is based on semantics, which lets it admit some natural but previously problematical specifications. The semantic conditions are discharged by the program verifier using an SMT solver, and the paper describes heuristics that help avoid common problems in finding witnesses with trigger-based SMT solvers. The paper reports on the positive experience with using this approach in Spec# for over a year. IntroductionPure methods and model fields [1,2] are useful and common specification constructs. By marking a method as pure, the specifier indicates that it can be treated as a function of the state. It can then be called in specifications. Model fields provide a way to abstract from an object's concrete data. A problem with either technique is that it can introduce an inconsistency into the underlying proof system. In this paper, we discuss how to prove (automatically) that no such inconsistency is introduced while allowing a rich set of specifications.Starting from a review of the setting, the problem, and previous solutions, this section leads up to an overview of our contributions.Pure Method Specifications. Figure 1 shows the template for a pure method specification (for simplicity, we show only a single formal parameter, named p). As usual, requires declares the method's precondition P , ensures declares the method's postcondition Q , and result denotes the method's return value. The only free variables allowed in P are this and p. In Q , result is allowed as well.A Deduction System. Marking method m as pure adds an uninterpreted total function #m : C ×T → T (a method function [3]) to the specification language. In predicates in the specification, the expression E 0 .m(E 1 ) is treated as syntactic M.

Implicit dynamic frames

“…The composite design pattern (part 1). Middelkoop 2009;Rudich et al 2008]. We specifically chose very simple rules in our formalization to be able to focus on proving soundness of the permission system and to avoid unnecessary clutter in the proof.…”

“…Reasoning about method calls in specifications-and in particular, framing their return values-was posed as a challenge for verification by Leavens et al [2007]. Various researchers have attacked well-formedness of pure method specifications [Leino and Middelkoop 2009;Rudich et al 2008], framing of return values [Darvas and Leino 2007;Jacobs and Piessens 2007;Smans et al 2008], and allowing certain side effects in pure methods [Darvas and Leino 2007]. Just like most of these researchers, we encode pure methods as functions in the verification logic.…”

Formalised EMFTVM bytecode language for sound verification of model transformations

“…Using the execution semantics of the OP operator in the verification would trivially render any MT that is written in L as verified [26,27,44]. -An execution semantics of a MT language that is incorrect with respect to the runtime behaviour of the underlying implementation could lead to erroneous conclusions about the correctness of the MT (see Sect.…”

Compiling Hilbert's epsilon operator

“…Technically, with this restriction, the compiled let-such-that statement is no longer Hilbert's ε operator, but instead Russel's definite description operator [15], commonly denoted as the binder ι.…”