This is the mail archive of the
mailing list for the GCC project.
Re: named warnings & individual warning control
- From: "Joseph S. Myers" <jsm at polyomino dot org dot uk>
- To: DJ Delorie <dj at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 22 Jun 2004 15:38:53 +0000 (UTC)
- Subject: Re: named warnings & individual warning control
- References: <200406211908.i5LJ8mCX027121@greed.delorie.com>
On Mon, 21 Jun 2004, DJ Delorie wrote:
> Some folks argue that the warning text should be in the source, others
> note the benefits of having a machine-parsable warning catalog
> (documentation, for example). Both sides agree that gettext() is the
> i18n solution of choice.
I don't see why these are supposed to be mutually exclusive, given that
gettext illustrates how catalogs can be generated from the source.
Format warnings for diagnostics that don't agree with their arguments have
gone on, off (when extended formats such as %D were added), on (with some
checking for those), off (for some functions, which don't have the
attributes I think because of questions over use of such formats as %D in
the middle-end). How, with message text out of the source, would these
warnings operate (ensuring that each message uses only formats permitted
for that part of the compiler, and that they match the operands of the
format)? (Also, eyeballing messages in the source helps see that multiple
arguments of the same static type are in the right order for the message
> It should be easy to audit warnings to ensure that they're properly
> emitted in accordance with the selected standard.
Indeed, I've written testcases to ensure that warnings are or are not
pedwarns in appropriate modes, and fixed associated bugs where something
was the wrong one of a warning and a pedwarn. But many warnings don't yet
have such tests, and most of the tests just assert that something is an
error with -pedantic-errors without making an assertion it is just a
warning with -pedantic. The (pedantic && !flag_isoc99) tests are at least
visible in the source, but a warning control system may be able to do
things better so (a) it is still visible at the point the warning is
emitted that it is for something in C99 but not C90 and (b) you get a
-Wc90 option out of this for free. Maybe specify in the source both the
default state for the message (nothing, warning, error, with macros making
cases such as pedwarns and pedwarn for C90 / nothing for C99 more
convenient) and its identifier for individual control?
Naturally every warning should (ideally) have tests that its default
nature is right in all standard modes, and its own control mnemonic does
indeed control it. (The latter, testing all mnemonics, helps ensure the
stability Mark asked for.)
> The internal API should allow for both "emit warning if needed" and
> "is this warning enabled?" functionality, in case the source needs
> custom logic to select warnings.
Remember that not all warning options are such simple conditionals.
-Wwrite-strings for C changes the type of string constants rather than
enabling specific warnings. I don't think such options are going to be
feasible to control in the source this way, though most warning options
The devil is in the detail. There are many types of diagnostics,
including (here, "mandatory" means on by default without a present option
other than -w to turn it off, which would of course get finer control):
* Errors (not generally disablable, we don't try to generate sensible code
in their presence).
* Mandatory warnings.
* Mandatory pedwarns (these are warnings by default for C but errors for
* Warnings controlled by some option.
* Pedwarns if pedantic.
* Pedwarns if pedantic C90 (with a -Wc90 option, these should be pedwarns
if pedantic C90, otherwise warnings if -Wc90).
* Mandatory pedwarns in C99 mode that are off by default, but enabled as
warnings rather than pedwarns, for certain -W options in C90 mode.
(See pedwarn_c90 and pedwarn_c99, which centralise for special cases the
choice of pedwarn/warning but leave repetitive logic at the call sites to
decide when the warning happens at all.)
Also, what does or does not count as an individual warning that gets its
own control facility? Look at c-format.c, storing as much information as
possible about permitted formats in datastructures rather than code so
that the code is maintainable. (This will later need duplicating phrases
in the tables with distinguishing prefixes so that translations can
decline them differently in different messages.) This has its own ways of
determining whether a -pedantic warning is required (which need to handle
C94 differently from C90), and those -pedantic warnings are warnings not
pedwarns, and users might or might not want "%s does not support the
%<%%%c%> %s format" to count as one warning or several.
I had hoped general warning control would allow e.g. people to disable
those warnings for %m only (see bug 15338 and linked discussions). This
would be possible - adding lots of individual warning identifiers to the
tables, with the complication that many warnings arise from arbitrary
pairs of an entry in one table and an entry in another - should we do
(I do now think that additional -std options such as -std=posix2001 to
follow where appropriate standards that profile and extend C standards
will be desirable, including such things as syslog attributes even with
the duplication of printf format tables. There are other uses of such
options, for example allowing use of dlsym which presumes
interconvertibility of data and function pointers. But at present such
options seem lower priority to me than completing the support for the
underlying C standards of C90 and C99.)
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
email@example.com (personal mail)
firstname.lastname@example.org (Bugzilla assignments and CCs)