Re: Suppressing specific compiler warnings

[Stan Shebs <shebs at apple dot com>]

Andrew Pinski wrote:

> > Robert Dewar wrote:
> >
> >
> > > One general and significant drawback of these complex schemes
> > > for naming or numbering warnings is that they make it
> > > significantly more work to introduce new warnings, and that
> > > is an unfortunate scenario.
> > Part of my proposal of a year ago was to have the name be supplied
> > as part of the warning, so you'd say something like
> >
> >  if (...)
> >    WARN(unbuttoned_fly, "your fly is unbuttoned");
> >
> > where WARN is a macro that would expand into
> > "if (warn_unbuttoned_fly) warn (...);" etc.
> >
> > Whatever the details of the scheme, the mass of warning control
> > infrastructure should be auto-constructed.
>
> To me if someone does not want any warning they then should not
> care fo any, as the warnings in gcc are usually for there for a
> reason, like someone if gcc got bitten by that construct, aka
> signed vs unsinged warning.  Warnings can be disabled by -w and 
> that should be enough. Yes sometimes warnings are useful to disable
> like varargs macros being added only in C99 but that can be disabled
> now as we needed it for GCC itself.  Anyother warnings should be listen
> to and have the source fixed instead of just disabled the warnings.
To pick an example that occurs frequently in Mac OS X system
development, you can have headers that cause warnings in particular
sources, but after determining the warning is bogus, for instance
if the sources are correct and the headers are wrong, release cycles
may be such that the headers can't be fixed for awhile, maybe even
several months. In that case you want to suppress just the one warning
in one or a few places, but every other warning needs to stay on so
that -Werror etc will flag the genuinely problematic warnings.

Apple's internal developers have been saved weeks of hard debugging
by GCC's warnings, so they're generally big fans and want to turn
on as many warnings as possible.

Stan