[PATCH] Add new warning to Clang to detect when all code paths in a function has a call back to the function.

[Chandler Carruth]

Random thoughts...

On Fri, Nov 8, 2013 at 3:20 PM, Sean Silva <silvas at purdue.edu> wrote:

> 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?


Note that if this is a significant compile time issue, that's relevant.
Everything else is assuming that it isn't. =]

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)


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.

Almost all of our warnings "aren't needed" because they could be tested and
debugged. That doesn't remove their value.


> 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.


No, it's shortening the cycle time for developers that hit this bug.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131108/96dc4e98/attachment.html>