[cfe-dev] new -Wuninitialized implementation in Clang

[Ted Kremenek]

On Feb 4, 2011, at 8:12 AM, Nico Weber wrote:

> Suggestions:
> * I found your above explanation of how the analysis works very
> helpful. Maybe there could be a page with this explanation, it could
> also list common false positives and recommended work-arounds.

Yes, documenting the expected behavior makes a lot of sense.

> * Maybe add special cases for more common patterns to the checker. In
> chrome, |bool b = get(&a); b = b && get(&b); if(!b) return; use(a,
> b);| is somewhat common, and complements the existing |if(x && y &
> ...)| special case.

The 'bool b = ...' case isn't trivial to handle because it inherently requires tracking the value of 'b' across multiple statements and possibly multiple basic blocks.  It basically requires its own dataflow analysis to handle it generally enough for its behavior to be consistent and predictable.

> * If it warns, provide a way to explain the warning ("Variable could
> be uninitialized on this path: declared here, else branch here, then
> goto here, use here")


I'm mixed on this one.  This could possibly be done with notes, but I somewhat feel that this should remain the purview of the static analyzer.  The whole point of this warning is to be simple and to catch obvious uses of uninitialized values.

The reason that I am mixed is that if an uninitialized value warning requires a complicated explanation of what the code did to trigger the warning, I see two possibilities:

1) The code is too complicated for the simple -Wuninitialized analysis to handle, probably because of control-dependencies.

2) The code's logic to initialize a variable is inherently complicated anyway.

Concerning (1),  the options I see are:

(a) make the analysis smarter (if possible), either erring on suppressing warnings or just doing a better job.

(b) have the user disable the warning (for the particular case)

Concerning (2), for me if it takes longer than 5 seconds to be able to reason if the code initializes a variable then I think the code is structured poorly.  In such cases, even if the warning is wrong (and the variable is initialized) there is value in the warning because it indicates the code is overly complex.  From what I can tell, however, that's probably an outlier opinion on this thread.