Revision History

revision

D.3.2 [Programming Languages] Language Classifications — Object-oriented languages; F.3.1 [Logics and Meanings

of Programs] Specifying and Verifying and Reasoning about Programs

A sound assertion semantics for the dependable systems evolution verifying compiler

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.

On the Language Design and Semantic Foundation of LCL, a Larch/C Interface Specification Language

The specialization of a specification language to a particular programming language is an important characteristic of module interface specification languages (MISL's). The only well-developed MISL's are the Larch interface languages and among these LCL, a Larch/C interface specification language, would seem to be the most mature. Our efforts to elaborate a semantic model for LCL lead to the identification of inadequacies and insufficiencies in the language and its informal definition. After defining and motivating the concept of object dependency, we demonstrate that LCL lacks the necessary language constructs for specifying object dependency relationships. We illustrate shortcomings caused by implicit constraints that are related to function parameters and object trashing. We show that the implicit constraint associated with the trashing of objects results in a violation of the principle of referential transparency. The identified inadequacies and insufficiencies are overcome in LCL ,the variant of LCL described in this thesis. The main contribution of this thesis is a semantic model within which a core subset of LCL (consisting of constant declarations, variable declarations and function specifications) is formallydefined. We present the semantics in a style known as natural semantics. The meaning of the non-interface part of an LCL specification is captured byanembedding intoLSL. The primary notation used to write the semantics isZ. Wehavechosen to use LL, the logic underlying LSL, as the logical basis for LCL . tthe heart of the semantic model is our model of thestore. The storage model is exceptional in that it supports object dependencies in their full static generality..

Early detection of JML specification errors using ESC/Java2

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