<div dir="ltr"><div class="gmail_extra">Random thoughts...</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 8, 2013 at 3:20 PM, Sean Silva <span dir="ltr"><<a href="mailto:silvas@purdue.edu" target="_blank" class="cremed">silvas@purdue.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> At a higher level, is this really needed as a compiler warning? I mean, it's nice and all to detect these things statically, but is this really something that needs to be happening on every build?</blockquote>
<div><br></div><div>Note that if this is a significant compile time issue, that's relevant. Everything else is assuming that it isn't. =]</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 Could we just do this in the static analyzer? In practice, I can't imagine any of these being hard to debug "while developing", since they will always result in a stack overflow the second they are called (and then you just look at the core file (or the debugger that your IDE attached) to see which function it was)</blockquote>
<div><br></div><div>Your description alone is the evidence for why developers should have a warning. ;] First off, stack overflows are notoriously annoying to debug. Core files are often missing. Running under the debugger is yet another step to do. I would much rather the compiler just tell me about it.</div>
<div><br></div><div>Almost all of our warnings "aren't needed" because they could be tested and debugged. That doesn't remove their value.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So essentially it seems like this is finding bugs in code that has no test coverage and has never been executed in practice; that kind of "cleaning out crusty unused parts of the codebase" seems like it would be better left to the static analyzer.</blockquote>
</div><br>No, it's shortening the cycle time for developers that hit this bug.</div><div class="gmail_extra"><br></div><div class="gmail_extra">It also is cleaning out bugs in crufty code, which is always nice. Very few people will run the static analyzer over all of their crufty code because if they aren't changing it and it is working in production, they aren't going to want to sift through the false positives of "maybe that's a bug". Static analyzers run much more over code under active development.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">And fundamentally, we *routinely* do all of the static analysis that is sufficiently inexpensive and has sufficiently rare false positives at compile time. So I think we should focus on those two criteria, the latter one being the most interesting here.</div>
</div>