Suspicion of regression in uninitialized value detection

[David Brown]

On 06/12/2011 14:26, Richard Guenther wrote:
> On Tue, Dec 6, 2011 at 2:13 PM, Dave Korn<dave.korn.cygwin@gmail.com>  wrote:
>> On 05/12/2011 21:43, Jeff Law wrote:
>>
>>> When the uninitialized&  initialized to 10 paths meet, the compiler
>>> (correctly) pretends the value for the uninitialized path is 10 as
>>> well.
>>
>>   Wouldn't that be a good point at which to issue an uninitialised-use warning?
>
> No.  If it were we would be warning for conditionally uninitialized
> uses in the early uninitialized warning pass which we don't do
> because of the way too many false positives.
>
> Richard.

I would say it's better to have false positives in cases like this, than 
false negatives, because there are easy ways to remove the false 
positives.  It is exactly in cases like this, with complex conditional 
initialisations, that you want the warning to be sure that you've 
covered everything.  My impression (without having done careful testing) 
is that the compiler is quite good at spotting in which paths the 
variable is initialised and uninitialised, and that this has improved 
with newer versions of gcc.  This means the warning has the potential to 
be more accurate and thus more useful.

In cases when you know you've initialised the variable in all possible 
use cases, but the compiler can't see that, then you can initialise the 
variable to itself (as long as you don't use the -Winit-self flag) to 
disable the warning on that variable.  In the great majority of cases, 
you can also initialise the variable to some value without having any 
noticeable effect on the program size or speed.

Just my opinion, of course.

mvh.,

David