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 [EMAIL PROTECTED] (916) 791-8304
