{"scopus_import":1,"year":"2010","publisher":"Springer","volume":37,"date_created":"2018-12-11T11:47:01Z","user_id":"3E5EF7F0-F248-11E8-B48F-1D18A9856A87","publist_id":"7284","intvolume":"        37","oa_version":"None","status":"public","quality_controlled":"1","title":"Doomed program points","date_updated":"2021-01-12T08:01:28Z","month":"12","publication":"Formal Methods in System Design","day":"01","author":[{"last_name":"Hoenicke","first_name":"Jochen","full_name":"Hoenicke, Jochen"},{"full_name":"Leino, Kari","first_name":"Kari","last_name":"Leino"},{"first_name":"Andreas","last_name":"Podelski","full_name":"Podelski, Andreas"},{"first_name":"Martin","last_name":"Schäf","full_name":"Schäf, Martin"},{"last_name":"Wies","first_name":"Thomas","id":"447BFB88-F248-11E8-B48F-1D18A9856A87","full_name":"Wies, Thomas"}],"doi":"10.1007/s10703-010-0102-0","page":"171 - 199","type":"journal_article","abstract":[{"lang":"eng","text":"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 (&quot;noise&quot;) 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."}],"_id":"533","department":[{"_id":"ToHe"}],"language":[{"iso":"eng"}],"issue":"2-3","publication_status":"published","citation":{"ama":"Hoenicke J, Leino K, Podelski A, Schäf M, Wies T. Doomed program points. <i>Formal Methods in System Design</i>. 2010;37(2-3):171-199. doi:<a href=\"https://doi.org/10.1007/s10703-010-0102-0\">10.1007/s10703-010-0102-0</a>","ista":"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.","chicago":"Hoenicke, Jochen, Kari Leino, Andreas Podelski, Martin Schäf, and Thomas Wies. “Doomed Program Points.” <i>Formal Methods in System Design</i>. Springer, 2010. <a href=\"https://doi.org/10.1007/s10703-010-0102-0\">https://doi.org/10.1007/s10703-010-0102-0</a>.","apa":"Hoenicke, J., Leino, K., Podelski, A., Schäf, M., &#38; Wies, T. (2010). Doomed program points. <i>Formal Methods in System Design</i>. Springer. <a href=\"https://doi.org/10.1007/s10703-010-0102-0\">https://doi.org/10.1007/s10703-010-0102-0</a>","short":"J. Hoenicke, K. Leino, A. Podelski, M. Schäf, T. Wies, Formal Methods in System Design 37 (2010) 171–199.","mla":"Hoenicke, Jochen, et al. “Doomed Program Points.” <i>Formal Methods in System Design</i>, vol. 37, no. 2–3, Springer, 2010, pp. 171–99, doi:<a href=\"https://doi.org/10.1007/s10703-010-0102-0\">10.1007/s10703-010-0102-0</a>.","ieee":"J. Hoenicke, K. Leino, A. Podelski, M. Schäf, and T. Wies, “Doomed program points,” <i>Formal Methods in System Design</i>, vol. 37, no. 2–3. Springer, pp. 171–199, 2010."},"date_published":"2010-12-01T00:00:00Z"}