Abstract not found

... In this paper, we illustrate the subtle problems any encoding of method calls in specifications has to address. We present a sound encoding that allows side-effect free methods to create and initialize objects by explicitly modeling such modifications of the heap.

Abstract. The Java Modeling Language, JML, is an interface specification language that uses side-effect free Java expressions to describe program behavior. In particular, JML specifications can contain calls to side-effect free methods. To verify programs w.r.t. JML specifications, JML expressions have to be encoded in a program logic. This encoding is non-trivial for method calls. In this paper, we illustrate several subtle problems any program verifier for JML has to address. We present an encoding of method calls that handles abrupt termination, allows methods to create and initialize objects, and is sound, even if the JML specification is not satisfiable. 1

Abstract. Contract languages such as JML and Spec # specify invariants and pre- and postconditions using side-effect free expressions of the programming language, in particular, pure methods. For such contracts to be meaningful, they must be well-formed: First, they must respect the partiality of operations, for instance, the preconditions of pure methods used in the contract. Second, they must enable a consistent encoding of pure methods in a program logic, which requires that their specifications are satisfiable and that recursive specifications are well-founded. This paper presents a technique to check well-formedness of contracts. We give proof obligations that are sufficient to guarantee the existence of a model for the specification of pure methods. We improve over earlier work by providing a systematic solution including a soundness result and by supporting more forms of recursive specifications. Our technique has been implemented in the Spec # programming system. 1

TLA+ is a language intended for the high-level specification of reactive, distributed, and in particular asynchronous systems. Combining the linear-time temporal logic TLA and classical set-theory, it provides an expressive specification formalism and supports assertional verification.

Abstract The interface specification of a procedure describes the procedure's behavior using pre- and postconditions. These pre- and postconditions are written using various functions. If some of these functions are partial, or underspecified, then the procedure specification may not be well-defined. We show how to write pre- and postcondition specifications that avoid such problems, by having the precondition "protect " the postcondition from the effects of partiality and underspecification. We formalize the notion of protection from partiality in the context of specification languages like VDM-SL and COLD-K. We also formalize the notion of protection from underspecification for the Larch family of specification languages, and for Larch show how one can prove that a procedure specification is protected from the effects of underspecification.

The Verifying Compiler (VC) project is a core component of the Dependable Systems Evolution Grand Challenge. The VC offers the promise of automatically proving that a program or component is correct, where correctness is defined by program assertions. While several VC prototypes exist, all adopt a semantics for assertions that is unsound. This paper presents a consolidation of VC requirements analysis activities that, in particular, brought us to ask targeted VC customers what kind of semantics they wanted. Taking into account both practitioners ’ needs and current technological factors, we offer recovery of soundness through an adjusted definition of assertion validity that matches user expectations and can be implemented practically using current prover technology. We describe how support for the new semantics has been added to ESC/Java2, one of the most fully developed VC prototypes. Preliminary results demonstrate the effectiveness of the new semantics at uncovering previously indiscernible specification errors. 1

www.cs.concordia.ca/~chalin Abstract. Early in the design of the Java Modeling Language (JML) care was taken in the choice of its logical foundation to ensure that JML could accommodate run-time assertion checking, static analysis and formal verification. At the time, classical two-valued logic was adopted. Since then however, we note that the main JML tools have actually implemented differing semantics, by design. In this paper, we begin by reviewing the current logical semantics of JML and explore some of the ramifications of this choice. We then present the results of a survey of programmers from industry, i.e. JML's targeted end users. We asked them how they want assertions to be interpreted during run-time checking and static verification. Survey results indicate that developers are in favor of a semantics for assertions that is compatible with their current use in runtime checking, and hence consistent with a three-valued logic in which partial functions are modeled explicitly.

. The data-parallel programming model is currently the most successful model for programming massively parallel computers. Unfortunately, it is, in its present form, restricted to exploiting flat data parallelism, which is not suitable for some classes of algorithms, e.g. those operating on irregular structures. Recently, some effort has been made to implement nested data-parallel programs efficiently by compiling them into equivalent flat programs using a transformation called flattening. However, previous translations of nested into flat data-parallel programs have proved unwieldy when it comes to inventing and specifying optimizations and verifying the translation. This paper presents a new formalization of the flattening transformation in a calculational style. The formalization is easily verified and provides a good starting point for the development of new optimizations. Some optimizations invented on the basis of this new formalism are described. Furthermore, we present practica...

The earlier errors are found, the less costly they are to fix. This also holds true of errors in specifications. While research into Static Program Verification (SPV) in general, and Extended Static Checking (ESC) in particular, has made great strides in recent years, there is little support for detecting errors in specifications beyond ordinary type checking. This paper reports on recent enhancements that we have made to ESC/Java2, enabling it to report errors in JML specifications due to (method or Java operator) precondition violations and this, at a level of diagnostics that is on par with its ability to report such errors in program code. The enhancements also now make it possible for ESC/Java2 to report errors in specifications for which no corresponding source is available. Applying this new feature to, e.g., the JML specifications of classes in java.*, reveals over 50 errors, including inconsistencies. We describe the adjustment to the assertion semantics necessary to make this possible, and we provide an account of the (rather small) design changes needed to realize the enhancements.