Toward special-purpose program verification

Abstract

Program verification has seen little practical, automated use. How can its good ideas be revived in a practical setting? One way is to lower its sights: instead of checking that a program matches its specification, one can perform less ambitious but more feasible checking. Much recent work has lowered sights by checking only specifications and not programs. By characterizing software failures by their detection method, we have decided instead to try checking only programs and not specifications. Our goal is to integrate run-time checking into a compiler, so that programs never commit common run-time faults like following bad pointers or violating array boundaries. 1 Verification ignored Most work in applying formal methods to software development concentrates on formalizing software designs, because it is a challenging intellectual problem that brings forth fundamental issues in programming methods and notations. Thus program verification, which arose from axiomatic semantics [Ho691, was originally developed in an ambitious attempt to produce programs that “do what we want them to do.” [Lo751 After an burst of enthusiasm, however, researchers found that program verification consumed too many human resources to apply it to practical systems. Although serious work has continued in program verification to this day, many outsiders are skeptical of its utility. For example, of 25 papers in a recent conference on practical software development environments [He881, only two relatively speculative papers [Le88, Re88) even mentioned verification. Another measure of the distance between formal verification and practice is the Gypsy Programming Support Environment [Co88], named by practical workers who were evidently unaware of the Gypsy Verification Environment [Go861! Many workers who remain in the field concentrate on verifying only the most crucial properties of software, notably security in the U.S.A. [Ch81, Go86, vH88, Sc891, where sights axe often lowered by checking only specifications, not programs. This work is not likely to catch on in the broader software community. Worse, software engineering education, at least in the U.S.A., discourages students from formal methods [Gr90]. Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for Proceedings of the ACM SIGSOFT International Workshop on Formal Methods in Software Developdirect commercial advantage, the ACM copyright notice and the ment. Napa, California, May 9-11, 1990. title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. @ 1990 ACM 089791-4155/90/0010-0025...$1.50