{"scopus_import":1,"issue":"2-3","status":"public","oa_version":"None","date_updated":"2021-01-12T08:01:28Z","publication_status":"published","type":"journal_article","publist_id":"7284","publication":"Formal Methods in System Design","date_published":"2010-12-01T00:00:00Z","citation":{"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>.","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>.","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.","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.","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>"},"volume":37,"year":"2010","publisher":"Springer","month":"12","intvolume":"        37","day":"01","quality_controlled":"1","user_id":"3E5EF7F0-F248-11E8-B48F-1D18A9856A87","author":[{"first_name":"Jochen","last_name":"Hoenicke","full_name":"Hoenicke, Jochen"},{"first_name":"Kari","full_name":"Leino, Kari","last_name":"Leino"},{"first_name":"Andreas","last_name":"Podelski","full_name":"Podelski, Andreas"},{"first_name":"Martin","full_name":"Schäf, Martin","last_name":"Schäf"},{"id":"447BFB88-F248-11E8-B48F-1D18A9856A87","first_name":"Thomas","last_name":"Wies","full_name":"Wies, Thomas"}],"date_created":"2018-12-11T11:47:01Z","_id":"533","abstract":[{"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.","lang":"eng"}],"page":"171 - 199","title":"Doomed program points","doi":"10.1007/s10703-010-0102-0","language":[{"iso":"eng"}],"department":[{"_id":"ToHe"}]}