Uninitialized variable warnings

[Zack Weinberg]

On 15 Mar 1999 10:39:33 -0000, craig@jcb-sc.com wrote:
>>There are a number of other places where gcc has gotten it wrong, and
>>a few places where the warning indicates a real bug.  There's also one
>>worrisome case, where we get it right or not unpredictably:
>>
>>if(x == THING_1) var = val1;
>>else if(x == THING_2) var = val2;
>>else if(x == THING_3) var = val3;
>>...
>>else abort();
>>...
>>use(var);
>
>Could you be more precise about "unpredictably"?  Specifically, do you
>mean it's unpredictable all the way down to identical chunks of code
>(in separate functions, say) compiled a *single* time?  Or across
>multiple runs of the exact same compiler?  Or do you just mean it's
>unpredictable across compiler targets (which might be explained by
>differences in whether abort() is known to have its noreturn attribute)?

I mean that given two similar chunks of code one will get a warning
and the other won't, and the significant difference may seem to be
absolutely irrelevant as far as a human is concerned.  A good example
is the `plist' variable in objc-act.c:generate_protocol_list.  We warn
on that.  Prune everything else out of the function, and the compiler
doesn't warn anymore.

The compiler is consistent across multiple runs on the same code.
Header file issues are a red herring - abort() is hardwired as
noreturn in c-decl.c.

zw