named warnings & individual warning control

[llewelly@xmission.com]

David Taylor <dtaylor@emc.com> writes:

> > Date: Fri, 25 Jun 2004 14:25:07 -0400
> > From: DJ Delorie <dj@redhat.com>
> > 
> > > >Also, -O[23] tends to confuse this as they defer the use of warning
> > > >flags until after the whole file is parsed, so pragmas between
> > > >function definitions don't do what you expect :-(
> > >
> > > I'm not sure what to say about the problem in the last paragraph; that's 
> > > clearly a serious user interface issue.  This is part of why I have long 
> > > argued that only front ends should be permitted to issue warnings, and 
> > > that all attempts to use back-end data flow analysis to issue warnings 
> > > are mistaken, no matter how clever they seem.
> > 
> > Barring huge changes in the design of the internals of gcc, I'm happy
> > with documenting that such pragmas should come before any functions in
> > the source or else they may not apply.  That's in line with the "the
> > user shouldn't be doing this unless they absolutely have to" theory.
> 
> Putting on my user hat --
> 
> I have for years wanted the ability to turn individual warnings off
> for small parts of a file.  If I have to put the pragma before all
> the functions -- i.e., if it applies to the whole file, nothing
> smaller -- then I don't think it's worth the effort to implement it.
> 
> Seriously.  We already have a solution to that problem -- it's
> modifying the command line switches used to compile the file.  If the
> warning pragma applies to an entire file, I don't think we'll bother
> to use it.  If it applies to individual functions, we might use it.
> If it applies to individual lines (i.e., arbitrary code until the next
> pragma that changes it or the end of the file), we will use it.

As a user, I strongly agree with this.