[cfe-commits] [cfe-dev] How to fix null-deref-ps.c on FreeBSD?
kremenek at apple.com
Tue Feb 17 10:51:42 PST 2009
On Feb 17, 2009, at 10:42 AM, Alexei Svitkine wrote:
> If a panic function is in user code, is the analyzer smart enough to
> figure out that function never returns by looking at the code (ie all
> branches lead to _exit() or another panic function)?
The analyzer cannot do this right now, but that kind of inter-
procedural analysis is something we'd like to do one day.
In general functions that cannot return should indicate that fact with
a 'noreturn' attribute so that the compiler can generate better code.
We certainly could add a local analysis check to warn users about
functions that should be marked 'noreturn' because they always call a
known panic function.
Some functions, however, are "conditional" panic functions, where they
only abort a program when a passed argument is equal to a specified
value. This actually happens quite a bit in the Postgresql codebase,
which leads to a bunch of false positives from the analyzer. The
solution for handling such functions is to do build up path-sensitive
(and potentially context-sensitive) summaries for functions that
indicate that "if argument X has the value 'error' then this function
doesn't return". Then when we analyze a function that calls the panic
function we just consult the summary to see if the function doesn't
return given the current set of arguments.
In general, doing this kind of analysis doesn't just require inter-
procedural analysis, but it requires doing a whole-program analysis
across multiple source files. This is necessary because the
definition for the panic function itself likely occurs in one specific
file. Doing this kind of whole-program analysis requires some
infrastructure that is a big TODO for the analyzer. Having this kind
of whole-program analysis in place would also open the door for doing
a lot more sophisticated checks.
More information about the cfe-commits