Suppressing specific compiler warnings

[Stan Shebs]

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