1. The ideal of program correctness Tony Hoare BudapestSeptember 2006

2. Basic questions of Engineering What does the product do? –what is the specification? How does the product work? –what are its components? –what are their interfaces? –how are they connected?

3. Basic questions of Science Why does it work? –what scientific theory does it rely on? How do we know the answers are correct? –by experiment, –by calculation, –by proof –all checked by computer.

4. A program verifier automatically checks that a program conforms to its specification serves as an essential tool for research into the science of programming. proposed in 1969 still a Grand Challenge for Computing research

5. A Grand Challenge project (eg. the Human Genome 1991-2004) pursues scientific ideals involves hundreds of scientists with many specialist skills for many years delivers a measurable outcome with prospects of widespread exploitation

6. Program Correctness is a scientific ideal like accuracy of measurement in physics purity of materials in chemistry completeness of theory in logic pursued for its own sake beyond the needs of the present market because one day.....

7. A measurable outcome One million lines of verified code plus specifications, designs, assertions,... machine-checked by a program verifier at various levels of assurance with hundreds of programs/modules of various sizes: 100 to 100K lines drawn from a wide range of applications held in a public Repository.

8. Levels of assurance 1.freedom from overflows, exceptions 2.soundness of internal interfaces 3.continuity of service (crash-proofing) 4.resistance to intrusion (security) 5.avoidance of damage (safety) 6.total functional correctness (the ideal)

9. Applications drawn from critical systems embedded control operating system kernels web services desktop applications open source library classes program generators compilers...

10. Repository conserves programs verified so far and the tools that checked them and the relevant journal record. Also: challenge codes not yet verified and specifications not yet coded and tools that apply to them... selected by the research community

11. Tools design environments reverse engineering aids test case generators program analysers verification condition generators model checkers, decision procedures, constraint satisfiers, proof engines......all contributing to the program verifier

12. Vision software based on rational design programmers make less mistakes mistakes are detected immediately software is delivered sooner evolves more easily resists attack from virus/worm/spam and is cheaper to develop and use

13. Cheaper “Based on [our] software developer and user surveys, the [US] national costs of an inadequate infrastructure for software testing is estimated to range from $22.2 to $59.5 billion. Over half these costs are borne by users...” The Economic Impact of Inadequate Infrastructure for Software Testing. Planning report 02-03, National Institute of Standards & Technology, May 2002.

14. Many skills Theory –to cover pointers, inheritance, concurrency,... Tools –exploit the theory in analysers, checkers, VC generators, provers, decision procedures,... Experiments –apply the tools to verify the challenge codes and specifications –provide feedback for tool evolution

15. Theory Theories abound. They must be unified and integrated and developed for incorporation in tools for application by other scientists...and later by software engineers

16. Tools Tools are exciting and prestigious. They need maintenance and customer support They need adaptation for inter-working and later for integration allowing continued separate evolution... to meet user needs

17. Experiments Experiments are hard work. They apply other peoples’ prototype tools to other peoples’ realistic programs to reach scientifically valid conclusions and gain experience for later advances (... that will make earlier work trivial)

18. IFIP Working Conference Verified Software: theories, tools, experiments. Zurich: 10 -14 Oct. 2005 Chairmen: Tony Hoare, Jay Misra, Natarajan Shankar Sponsor: IFIP WG2.3 (programming methodology)

19. A Program Verifier One can dream of routinely using a verifying compiler as an everyday tool. In the context of this idea our work has been extremely modest and must be considered as a small first step. We only hope that, indeed, this has been a first step of a progression which will allow this dream to come to fruition. A Program Verifier Thesis by James C. King Carnegie Institute of Technology September 1969