[cfe-dev] new -Wuninitialized implementation in Clang

[Nico Weber]

On Thu, Feb 3, 2011 at 10:34 PM, Ted Kremenek <kremenek at apple.com> wrote:
> On Feb 3, 2011, at 9:34 PM, Nico Weber wrote:
>
>> 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'm not certain if the second statement is truly fair.  This is code that has already been vetted for uses of uninitialized values.

Yes. Then again, this is probably true for many existing code bases :-)

If you're interested in data on how this does on new code, I can
temporarily check in my workaround changes for chrome, turn the
warning on on our clang/mac bot, and in two weeks send a report on the
things it warned about.

> Your point is taken, however, that the remaining false positives are noise that GCC doesn't warn about.  The question I'd rather we focus on asking is what should we do about those cases?

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.
* 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.
* 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")


Unrelated: From an implementation perspective, s it reasonable to
propagate __attribute__((noreturn))? I noticed that |int a; _exit(0);
use(a);| does not warn, but |void g() { _exit(0); } int a; g();
use(a);| does.

Nico