Re: Build problem

[<br...@ph...>]

Ethan A Merritt wrote:
> On Saturday 08 July 2006 12:22 pm, Hans-Bernhard Br=F6ker <broeker@=
physik.rwth-aachen.de> wrote:
>> [gcc -Wuninitialized warnings]

>>> I don't know of any way to make gcc more accurate in such cases.
>> Well, just initialize them!  Worst that can happen is that the cod=
e=20
>> gratuitously grows by 3 'load value into variable' operations.  *I=
f*=20
>> they're actually false alarms, that is.
>=20
> Not quite.  The worst thing that can happen is that by initializing
> to some spurious value, you trigger run-time errors that are no lon=
ger
> accompanied by a relevant compiler warning. =20

You've just demonstrated the reason why I wrote: "*If*" they're actua=
lly=20
false alarms".  A -Wuniniatilized can be a false alarm _only_ if all=
=20
code paths leading to  the place of the warning actually come by a wr=
ite=20
to the variable in question, but the compiler didn't understand the c=
ode=20
well enough to notice that.  If there's any way the dummy initializer=
=20
can survive to the place warned about, the alarm is not false.

> But if somehow the pair of if conditions are not truly
> equivalent, then you have a problem regardless of the fact
> that baz has been initialized. =20

If that happens, there was no false alarm to begin with.

There can really be only two cases.

1) False alarm.  Adding an initializer silences the warning, slightly=
=20
increases code size and burns some useless CPU cycles.  Nothing gaine=
d=20
except the warning is silenced, but no considerable harm done either.

2) Justified alarm.  This is a bug that needs to be fixed, and the fi=
x=20
will be to initialize that variable.  The only tricky question remain=
s=20
is what the initial value should be.

So, summing it up: initializing, even to the wrong value, is never wo=
rse=20
than not initializing at all, and it does get rid of the warning.