Abstract not found

Program verification is the idea that properties of programs can be precisely stated and proved in the mathematical sense. In this paper, some simple heuristics combining evaluation and mathematical induction are described, which the authors have implemented in a program that automatically proves a wide variety of theorems about recursive LISP functions. The method the program uses to generate induction formulas is described at length. The theorems proved by the program include that REVERSE is its own inverse and that a particular SORT program is correct. A list of theorems proved by the program is given. key words and phrases: LISP, automatic theorem-proving, structural induction, program verification cr categories: 3.64, 4.22, 5.21 1 Introduction We are concerned with proving theorems in a first-order theory of lists, akin to the elementary theory of numbers. We use a subset of LISP as our language because recursive list processing functions are easy to write in LISP and because ...

The Gypsy verification environment is a large computer program that supports the development of software systems and formal, mathematical proofs about their behavior. The environment provides conventional development tools, such as a parser for the Gypsy language, an editor and a compiler. These are used to evolve a library of components that define both the software and precise specifications about its desired behavior. The environment also has a verification condition generator that automatically transforms a software component and its specification into logical formulas which are sufficient to prove that the component always runs according to specification. Facilities for constructing formal, mechanical proofs of these formulas also are provided. Many of these proofs are completed automatically without human intervention. The capabilities of the Gypsy system and the results of its applications are discussed.

form a region with no exit. We might call such states S-states for Sisyphus who no matter how long he worked could never rest. Notice that deadlock states are just a special case of S-states in which a set of knotted processes have no non-e transitions. To put it another way if the first condition in the definition of "wait for" was changed so that the blocked processes could make non-e transitions but just could not reach a final state then S-states would be those in which a set of processes formed a knot. 4.5 Analyzing a System for Deadlock Analyzing a system for potential deadlock will involve generating some or all of a list R of the reachable system states. How much of R must be generated depends in part on the starting point of the analysis. Ideally one would observe a reachable state D in which two or more processes were blocked and then determine whether or not the blocked processes formed a knot. If no deadlock state D is suspected or if we are not sure it is re