[cfe-commits] [cfe-dev] How to fix null-deref-ps.c on FreeBSD?

[Ted Kremenek]

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.