Form Methods Syst Des (2010) 37: 171–199 DOI 10.1007/s10703-010-0102-0 Doomed program points Jochen Hoenicke · K. Rustan M. Leino · Andreas Podelski · Martin Schäf · Thomas Wies Published online: 24 November 2010 © Springer Science+Business Media, LLC 2010 Abstract Any programming error that can be revealed before compiling a program saves precious time for the programmer. While integrated development environments already do a good job by detecting, e.g., data-flow abnormalities, current static analysis tools suffer from false positives (“noise”) or require strong user interaction. We propose to avoid this deficiency by defining a new class of errors. A program frag- ment is doomed if its execution will inevitably fail, regardless of which state it is started in. We use a formal verification method to identify such errors fully automatically and, most significantly, without producing noise. We report on experiments with a prototype tool. Keywords Reliability · Program falsification · Static checking 1 Introduction Some errors in software are easy to detect. If an error is easy to detect it is cheap to fix. For example, if the definite assignment analysis of a compiler detects that a program reads an unassigned variable, the compiler will notify the programmer and the programmer will fix it without further ado. There are several kinds of errors that can be detected this way. They all have in common that they are errors independent of the desired behavior of the program. Static analyses that are built into the compiler are able to detect some of these errors. These are the most pervasive of all static analyses. No programmer thinks about false alarms or Rice’s theorem when the compiler rejects her program. J. Hoenicke · A. Podelski · M. Schäf University of Freiburg, Freiburg im Breisgau, Germany K.R.M. Leino Microsoft Research, Redmond, WA, USA T. Wies ( ) Institute of Science and Technology, Klosterneuburg, Austria e-mail: wies@ist.ac.at