On 06/12/2011 14:26, Richard Guenther wrote:
On Tue, Dec 6, 2011 at 2:13 PM, Dave Korn<dave.korn.cyg...@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
