This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Suppressing specific compiler warnings
- From: Andrew Pinski <pinskia at physics dot uc dot edu>
- To: shebs at apple dot com (Stan Shebs)
- Cc: dewar at gnat dot com (Robert Dewar), dutta at india dot hp dot com (Banibrata Dutta), gcc at gcc dot gnu dot org, llewelly at xmission dot com, rmathew at gmail dot com ('Ranjit Mathew')
- Date: Thu, 27 May 2004 14:36:06 -0400 (EDT)
- Subject: Re: Suppressing specific compiler warnings
>
> 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.
Thanks,
Andrew Pinski