Hoenicke, Jochen; Leino, Kari; Podelski, Andreas; Schäf, Martin; Wies, ThomasISTA
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 fragment 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.
Formal Methods in System Design
171 - 199
Hoenicke J, Leino K, Podelski A, Schäf M, Wies T. Doomed program points. Formal Methods in System Design. 2010;37(2-3):171-199. doi:10.1007/s10703-010-0102-0
Hoenicke, J., Leino, K., Podelski, A., Schäf, M., & Wies, T. (2010). Doomed program points. Formal Methods in System Design. Springer. https://doi.org/10.1007/s10703-010-0102-0
Hoenicke, Jochen, Kari Leino, Andreas Podelski, Martin Schäf, and Thomas Wies. “Doomed Program Points.” Formal Methods in System Design. Springer, 2010. https://doi.org/10.1007/s10703-010-0102-0.
J. Hoenicke, K. Leino, A. Podelski, M. Schäf, and T. Wies, “Doomed program points,” Formal Methods in System Design, vol. 37, no. 2–3. Springer, pp. 171–199, 2010.
Hoenicke J, Leino K, Podelski A, Schäf M, Wies T. 2010. Doomed program points. Formal Methods in System Design. 37(2–3), 171–199.
Hoenicke, Jochen, et al. “Doomed Program Points.” Formal Methods in System Design, vol. 37, no. 2–3, Springer, 2010, pp. 171–99, doi:10.1007/s10703-010-0102-0.