The ideal of program correctness

Tony Hoare

CAV Seattle August 2006

Scientific ideals

• accuracy of measurement

• purity of materials

• completeness of logic

• correctness of programs

• simplicity of theory

• and certainty of answers

• to the relevant basic questions

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?

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.

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

A Grand Challenge project

• (eg. the Human Genome 1991-2004)

• pursues scientific ideals

• involves hundreds of scientists

• with many specialist skills

• delivers a measurable outcome

• with prospects of widespread exploitation

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.

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)

Applications drawn from

• critical systems• embedded control• operating system kernels• web services• desktop applications• open source library classes• program generators • compilers ...

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

Tools

• design environments• reverse engineering aids• test case generators• program analysers• verification condition generators• model checkers• proof engines ......all contributing to the program verifier

Exploitation

• 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

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.

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

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

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

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)

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)

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 VerifierThesis by James C. King

Carnegie Institute of TechnologySeptember 1969