Of the Stanford Computer Forum

✓ <kV &** THE STANFORD PASCAL VERIFIER DAVID C. LUCKHAM PREPARED FOR THE ELEVENTH ANNUAL MEETING OF THE STANFORD COMPUTER FORUM FEBRUARY 1979 *,' FOREWORD The Stanford Pascal verifier is an interactive program verification system. It automates much of the work necessary to analyze a program for consistency with its documentation, and to give a rigorous mathematical proof of such consistency or to pin-point areas of inconsistency. It has been shown to have applications as an aid to programming, and to have potential for development as a new and useful tool in the production of reliable software. This verifier is a prototype system. It has inadequacies and shortcomings. It is undergoing continuous improvement, and is expected to be used eventually in conjunction with other kinds of program analyzers. The purpose of this manual is to introduce the verifier to a wider group of users for experimentation. We hope to encourage both feedback, to help improve this system, and the development of other program analyzers. The verifier is coded in Maclisp, a version of Lisp developed at M.I.T. for PDP-10 computers. A compiled version of the verifier including the Maclisp environment requires 100k words of core. The present version can be expanded to a maximum of 175k words. How to read this manual The manual is divided into two parts. Part I is an introduction to the verifier. It contains a short survey of its features and components, and examples of its use. The reader who has completed Part I should be able to construct simple examples and run them. He should also have gained some idea of what the verifier can do and what inadequacies to expect. Part II is a manual for those users who embark upon serious experiments with the verifier. Chapter 1 lists the differences between standard Pascal and the documented Pascal that the verifier requires as input. The major differences are the required documentation. There are also some minor differences in code. This is because it is planned that the verifier will accept a more general programming language than Pascal including Modules and constructs for concurrent processing. There is no discussion of the extended language in this manual. Chapter 2 describes the toplevel user commands. Chapter 3 is a short description of the special purpose theorem provers. This tells the user what kinds of knowledge are "built in" and what he must describe to the verifier by means of axioms. Chapter 4 is about the Rule Language. This chapter is in two sections. The first describes the rule language and how to express logical axioms as rules; the second section gets into the intricacies of writing rules and why rules written one way may lead the verifier into much more 1 efficient proof searches than if they are written another way. Section I should be enough for many simple examples. Appendix A contains syntax charts similar to the charts given in the Pascal User Manual. Here one will find the syntax of user commands for running the verifier and the syntax of input to the verifier, i.e., programs, assertions, and rules. Appendix B is a list of parser error messages with a more detailed description of their meaning than is provided by the comments from the system. Appendix C presents the axiomatic semantics used by the verification condition generator. Acknowledgements We would like to acknowledge the contributions made to the development of the verifier by our colleagues Shigeru Igrashi, Ralph London, Nori Suzuki, and Scot Drysdale. 2 PARTI INTRODUCTION TO THE STANFORD PASCAL VERIFIER 1. Overview Section 2 gives a toplevel overview of the verifier and how it is used. Section 3 describes the assertion language, the language in which the specifications of a program and the accompanying internal inductive assertions must be written. There are some brief remarks about what kinds of internal inductive assertions are required. A full description of compulsory assertions is given in Part 11, Chapter 1, and this information is also contained in the syntax charts. Section 4 outlines some of the basic constructs of the rule language. Rules defining concepts used in assertions must be written in the rule language. Part 11, Chapter 4 gives more details about rules and how the theorem prover uses them. Section 5 gives a number of examples illustrating the use of the verifier. The first few are quite simple and should be sufficient to enable the reader to run some simple examples of his own. The final example, on verifying a parser, illustrates formulation of rules from mathematical theories and the use of the verifier in debugging and improving specifications. At this point the reader is in a position to begin finding his own ways of making the verifier useful to himself. The methodology of using such systems is by no means fully explored. Further examples of verification experiments are given in the references at the end of Part 11. 2. The Verifier The verifier employs the inductive assertion method due to Floyd [7] for reasoning about programs. Floyd's method was developed into a logic of programs by Hoare [11] and others [3, 14]. The verifier constructs its proofs within this logic of programs. It requires as input a Pascal program together with documentation in the form of ENTRY and EXIT assertions and inductive assertions at crucial points in the program. Fig. 1 shows what happens when the programmer gives this input to the verifier. The input goes first to a verification condition generator which gives as output a set of purely logical conditions called Verification Conditions (VCs). There is a VC for each path in the program. If all of the VCs can be proved, the program satisfies its specification. The next step is to try to prove the VCs using various algebraic simplification and proof methods. Those VCs that are not proved are displayed for analysis by the programmer. If a VC is incorrect, this may reveal a bug in the program or insufficient documentation at some point. A modification is made to the input and the problem is rerun. If the unproven VCs are all correct this merely indicates that the proof procedures need more mathematical axioms. The programmer can state these in the rule language and input them. Ideally, the time for a complete cycle (Fig. 1) in a modern interactive computing environment should be of the order of a minute for a one page program. 3 Part I: Introduction to the Stanford Pascal Verifier Input 1 Verification i Program ► VCG » PROVER and 1 Condit i ons > Documentationon I S i mp lift ed VCs I Modified ANALYSIS OF « OUTPUT Problem I This contains a parser and a Verification Condition Generator (VCGEN). VCGEN uses axiomatic semantics of the programming language to generate VCs. We chose Pascal because at that time it was the only language for which such an axiomatic semantics within Hoare's logic of programs had been given [13]. VCGEN simply takes the place of the code generator in a compiler. The program together with inductive assertions is parsed for syntax and type compatibility (see Chapter 1 for details). The result is an internal tree representation from which the VCs are constructed by transforming the inductive assertions as a function of the code. The transformations correspond to axiomatic proof rules defining the meaning of the programming language constructs. The theory of VCGEN is presented in [14]. The important point is that if all of the VCs can be proved then there is a proof within the logic of programs that the given program satisfies its ENTRY/EXIT assertions and also that each subsection of the program satisfies its surrounding inductive assertions. Such a proof can be constructed by reversing the transformations that were applied by VCGEN. So, the VCs are sufficient conditions for correctness, but not always necessary ones. The truth of the VCs often depends on how completely the inductive assertions describe sections of the code. As a matter of practical convenience, the programmer should not be forced to supply documentation beyond what is necessary to understand the program. The transformations currently used by VCG are combinations of the axiomatic semantic rules of Pascal. The objective of such combinations is to reduce the number of situations in which the user has to repeat his assertions in trivial and tedious ways (this was a problem with earlier verifiers). The basic 4 V Part I: Introduction to the Stanford Pascal Verifier assertion requirements are that procedure and function declarations must have ENTRY/EXIT specifications, and loops within the body of the program must have invariant assertions. It is not necessary to place assertions at all GOTO labels. There are other required assertions (e.g., for global variables) and the details of these are in Chapter 1. It is easy to modify VCG for other languages that have axiomatic semantics formalizable within the logic of programs. No other component of the verifier depends on the input programming language. 2.2 The theorem prover This is the most complex component of the verifier. The major issue in its design is the trade-off between generality (i.e., logical completeness) of the prover and its average response time to given problems. If the theorem prover is very general, it takes too long to prove VCs and the user gives up waiting. If it is too restricted in its logical power and requires to be told too many trivial facts (e.g., x + I < y -* x <y) the user will give up trying to discover everything he must tell it. We have tried to solve this response time problem by using special purpose provers and by using algebraic simplification.

Load more