public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
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.

  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).