Re: -Wuninitialized issues

[Mark Mitchell <mark at codesourcery dot com>]

Jeffrey A Law wrote:
> On Mon, 2005-10-31 at 17:11 -0800, Mark Mitchell wrote:
> 
> 
>>>Certainly if we can't prove f always returns a nonzero value, then a
>>>warning should be issued.  If we do prove f always returns a nonzero
>>>value, then I think it becomes unclear if we should generate a warning.
>>
>>I don't think it's unclear; I think it should be a warning. :-)  The
>>fact that f always returns a nonzero value may be a function of
>>something about the current environment; I think people want this
>>warning to tell them something about the code, semi-independent of the
>>current environment.  It may be that I've got different ideas about how
>>this ought to work from some others in the community.
> 
> We clearly disagree then.  Though my 15+ years of working with GCC I've
> seen far more complaints about false positives than missing instances
> of this warning.

OK, sure; we can agree to disagree.

> I think the answer here is that there is no single answer that works
> best for everyone.  I hate to say that because I don't like the always
> problematical "switch creep" in GCC, but I feel in this case giving the
> user control over whether or not they want these additional warnings is
> warranted.

I think that's probably right.  Ada already issues these kinds of
warnings from the front-end, precisely to solve the kinds of user
complaints I'm raising; if we're going to avoid doing that in other
front-ends, we need to find some way to meet in the middle.  A switch
may be the least bad alternative, for all concerned.

>>Why doesn't that boil down to just warning about all the variables
>>marked by the first pass, either right at the time of the first pass, or
>>later during the second pass?
> 
> It boils down to being able to issue distinct warnings for the two
> cases.  There's a difference between noting that a variable might have
> been used uninitialized and noting that a variable might have been
> used uninitialized, but those problem uses were removed due to
> optimizations or certain paths in the CFG were proven unexecutable.

OK, now I get it.  Yes, being able to distinguish these classes seems
useful.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304