[cfe-dev] new -Wuninitialized implementation in Clang

[John N. Lehner]

On Feb 3, 2011, at 8:27 PM, Johannes Schaub (litb) wrote:

> Ted Kremenek wrote:
> 
>> My design goal for -Wuninitialized was threefold:
>> 
>> (a) Works under -O0.  Users care about seeing these warnings the most when
>> they are doing their debug builds.
>> 
>> (b) Has consistent results that are invariant of the optimization flags,
>> target architecture, phases of the moon, etc.
>> 
>> (c) Provides predictable results that are (for the most part) sound and
>> complete.
>> 
>> (d) Has marginal impact on compile time.
>> 
>> The last three goals mean that the analysis can only do limited reasoning
>> about control-dependencies, e.g.:
>> 
>>  int x;
>>  ...
>>  if (flag)
>>    x = ...
>>  ...
>>  if (flag)
>>    use(x);
>> 
>> Inherently analyzing this code correctly requires path-sensitive analysis,
>> which inherently has exponential cost in the general case.  There are
>> tricks where we can mitigate such algorithmic complexity for some common
>> cases, but handling these control-dependencies in general is something
>> that really is in the purview of the static analyzer.  Amazingly, GCC
>> often doesn't flag warnings in such cases, but I suspect that it is
>> because GCC is silently dropping warnings in some cases where it deems it
>> can't accurately reason precisely about a given variable.
>> 
> 
> Hmm, I would personally like to not initialize variables that I know are not 
> read from, as in your above code example. I personally regard it as bad 
> coding style to initialize variables with values not really used by the 
> code. 

I follow this philosophy as well (but my coworkers think I'm crazy).  While blindly initializing all variables to, say, zero will decrease the likelihood of nondeterministic runtime behavior, it doesn't necessarily contribute to program correctness.  What if the above example was "fixed" to suppress a spurious warning, but is then extended during maintenance:

int x = 0;
...
if (flag)
  x = ...
...
if (flag)
  use(x);
...
use(x);

and use(0) is wrong.  While that may seem contrived, I saw it happen in a loop once, and use(0) turned out to be expensive.

John