From: Neil Booth <neil@daikokuya.co.uk>
To: Zack Weinberg <zack@codesourcery.com>
Cc: gcc@gcc.gnu.org
Subject: Re: [RFC] __extension__ and warnings
Date: Wed, 11 Dec 2002 15:54:00 -0000 [thread overview]
Message-ID: <20021211231733.GA6610@daikokuya.co.uk> (raw)
In-Reply-To: <87of7si2w4.fsf@egil.codesourcery.com>
Zack Weinberg wrote:-
> The spec for pedwarn and pedantic, as I understand it, which may be a
> bit out of date, is:
>
> - If and only if the diagnostic in question is mandated by the
> relevant standard (C89, C99, C++98, F77, etc) use pedwarn()
> (unless you are using error() instead).
>
> - If, despite this, we do not think the warning should be on by
> default, put the pedwarn call under if (pedantic) or possibly
> if (pedantic||Wall).
>
> The spec for __extension__ is, it asserts that the following
> expression makes deliberate use of GNU extensions under proper
> #ifdeffage, so don't bug the programmer about it. Some, but not all,
> GNU extensions draw mandatory diagnostics; others are properly
> complained about by -Wtraditional and the like. So the two properties
> are somewhat orthogonal.
>
> I'm now imagining turning the DT_* enumeration into a set of bitflags,
> so that you could write e.g.
>
> diagnostic (DT_EXTENSION | DT_MANDATED | DT_WARNING, "...")
>
> to achieve the effect of 'pedwarn but shut up under __extension__.'
I prefer this. Fancy changing all error(), warning(), pedwarn(), ...,
calls? 8-)
Neil.
next prev parent reply other threads:[~2002-12-11 23:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-11 14:16 Neil Booth
2002-12-11 14:19 ` Gabriel Dos Reis
2002-12-11 22:55 ` Mark Mitchell
2002-12-11 15:17 ` Zack Weinberg
2002-12-11 15:54 ` Neil Booth [this message]
2002-12-11 23:54 ` Neil Booth
2002-12-11 23:58 ` Gabriel Dos Reis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20021211231733.GA6610@daikokuya.co.uk \
--to=neil@daikokuya.co.uk \
--cc=gcc@gcc.gnu.org \
--cc=zack@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).