[cfe-dev] new -Wuninitialized implementation in Clang

Ted Kremenek kremenek at apple.com
Thu Feb 3 21:57:51 PST 2011


On Feb 3, 2011, at 9:34 PM, Nico Weber wrote:

> Yet code that looks very similar does not warn:
> 
>    double expiry;
> 
>    if (!state->GetBoolean("include_subdomains", &include_subdomains) ||
>        !state->GetString("mode", &mode_string) ||
>        !state->GetDouble("expiry", &expiry)) {
>      continue;
>    }

Because this idiom is so common and because it is localized I was able to engineer the analysis to have just the necessary path-sensitivity to handle this case.


> 
> 
> This code (not chrome code), which _does have_ a legitimate
> uninitialized read, on the other hand does _not_ warn:
> 
> bool g(int* a) {
>  return true;
> }
> 
> int f() {
>  int a;
>  if (g(&a)) return a;
>  return a;
> }

The analysis is not inter-procedural.  It gives up when it sees the address of a variable taken.

Note that GCC will only warn about this case if it decides to inline the call to 'g'.  If 'g' is in another source file, or simply isn't inlined, GCC doesn't emit a warning either.

> My personal impression is that it can be difficult to understand when
> this new mechanism warns, and most of the time when it warns, it's
> warns about false positives.


I disagree.  I think the behavior is very predictable.  The analysis conservatively scans control-flow branches for uses of uninitialized variables, and takes a conservative estimate at confluence points.  This is the the textbook example of uninitialized variables.

The cases where it doesn't warn are:

1) The address of a variable is taken.  This is necessary because without pointer analysis one cannot determine if the value has escaped and has been initialized somewhere else.

2) The few cases where we can engineer the analysis to be smart enough to get just amount of path-sensitivity to not warn.  The most common case I saw was the if(x && y && ...) idiom, and that can be easily handled because it is localized.

We can make the analysis more predictable by removing (2), but it would make the warning far more noisy.



More information about the cfe-dev mailing list