formats and syslog question

formats and syslog question

[Marc Espie]

in -pedantic mode, gcc complains about %m.
But syslog, as per Single Unix, includes %m as a standard format specifier.

Question: how can we support syslog (which looks desireable to me) ?
Add a syslog format that is almost printf ?

What would be the logic wrt ansi language variants ? Namely, syslog is not
ansi at all. I'd assume no warning at all, as long as the right header is
included, and thus no built-in as well...
there is no switch corresponding to single unix or posix built-ins yet, right ?

Re: formats and syslog question

[Joseph S. Myers]

On Wed, 11 Sep 2002, Marc Espie wrote:

> in -pedantic mode, gcc complains about %m.
> But syslog, as per Single Unix, includes %m as a standard format specifier.
> 
> Question: how can we support syslog (which looks desireable to me) ?
> Add a syslog format that is almost printf ?
> 
> What would be the logic wrt ansi language variants ? Namely, syslog is not
> ansi at all. I'd assume no warning at all, as long as the right header is
> included, and thus no built-in as well...
> there is no switch corresponding to single unix or posix built-ins yet, right ?

syslog is treated just like a random user function that wraps the ISO C
functions (for which ISO C checking with -pedantic is appropriate).  
Allowing for such functions to vary what standard a particular specifier
is considered to be in, as well as adding or removing specifiers or
defining whole new format types, is something that should go in extensible
format checking (listed as "Maybe eventually" on the projects list).

-std options for standards such as Single Unix that add to ISO C would be
of some use (avoiding -pedantic warnings for the features they add to
*printf), but wouldn't help with syslog since %m is only a syslog format
in Single Unix, not a general printf one.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: formats and syslog question

[Marc Espie]

On Fri, Sep 13, 2002 at 01:11:28AM +0100, Joseph S. Myers wrote:
> On Wed, 11 Sep 2002, Marc Espie wrote:
> 
> > in -pedantic mode, gcc complains about %m.
> > But syslog, as per Single Unix, includes %m as a standard format specifier.
> > 
> > Question: how can we support syslog (which looks desireable to me) ?
> > Add a syslog format that is almost printf ?
> > 
> > What would be the logic wrt ansi language variants ? Namely, syslog is not
> > ansi at all. I'd assume no warning at all, as long as the right header is
> > included, and thus no built-in as well...
> > there is no switch corresponding to single unix or posix built-ins yet, right ?

> syslog is treated just like a random user function that wraps the ISO C
> functions (for which ISO C checking with -pedantic is appropriate).  
> Allowing for such functions to vary what standard a particular specifier
> is considered to be in, as well as adding or removing specifiers or
> defining whole new format types, is something that should go in extensible
> format checking (listed as "Maybe eventually" on the projects list).

Okay. I'm just going to look at adding a 'syslog' format, then.
Rationale: there are precious few portable formats, even in single unix.
And format checking is very, very useful in finding some classes of bugs.
Now, considering syslog(), you can very easily see that such bugs can be
critical very easily, as syslog() tends to be encountered in daemons and
such.

So, as it's not a standard we currently recognize, it will just exist as
a format one can add in a header with a prototype for syslog, not a
built-in.

Sounds okay ?

Re: formats and syslog question

[Daniel Jacobowitz]

On Fri, Sep 13, 2002 at 02:12:05PM +0200, Marc Espie wrote:
> On Fri, Sep 13, 2002 at 01:11:28AM +0100, Joseph S. Myers wrote:
> > On Wed, 11 Sep 2002, Marc Espie wrote:
> > 
> > > in -pedantic mode, gcc complains about %m.
> > > But syslog, as per Single Unix, includes %m as a standard format specifier.
> > > 
> > > Question: how can we support syslog (which looks desireable to me) ?
> > > Add a syslog format that is almost printf ?
> > > 
> > > What would be the logic wrt ansi language variants ? Namely, syslog is not
> > > ansi at all. I'd assume no warning at all, as long as the right header is
> > > included, and thus no built-in as well...
> > > there is no switch corresponding to single unix or posix built-ins yet, right ?
> 
> > syslog is treated just like a random user function that wraps the ISO C
> > functions (for which ISO C checking with -pedantic is appropriate).  
> > Allowing for such functions to vary what standard a particular specifier
> > is considered to be in, as well as adding or removing specifiers or
> > defining whole new format types, is something that should go in extensible
> > format checking (listed as "Maybe eventually" on the projects list).
> 
> Okay. I'm just going to look at adding a 'syslog' format, then.
> Rationale: there are precious few portable formats, even in single unix.
> And format checking is very, very useful in finding some classes of bugs.
> Now, considering syslog(), you can very easily see that such bugs can be
> critical very easily, as syslog() tends to be encountered in daemons and
> such.
> 
> So, as it's not a standard we currently recognize, it will just exist as
> a format one can add in a header with a prototype for syslog, not a
> built-in.
> 
> Sounds okay ?

Well, if you have an idea on a syntax for more extensible format
checking, as Joseph mentioned above, it'd be much nicer if you want
down that path.  For instance, Linux's printk() would very much like to
have format checking, but it can't at the moment because it has some
custom specifiers.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: formats and syslog question

[Marc Espie]

On Fri, Sep 13, 2002 at 11:24:15AM -0400, Daniel Jacobowitz wrote:
> Well, if you have an idea on a syntax for more extensible format
> checking, as Joseph mentioned above, it'd be much nicer if you want
> down that path.  For instance, Linux's printk() would very much like to
> have format checking, but it can't at the moment because it has some
> custom specifiers.

Sorry, no idea for a non-icky syntax yet.
On the other hand, I consider syslog() to be much more useful than printk,
as syslog is universal among unix systems, whereas printk is limited to
one single variant.  Maybe Jason R. Thorpe will have further ideas, as
I know that NetBSD has a custom version of the printf format for their
kernel printf ?

Re: formats and syslog question

[Joseph S. Myers]

On Fri, 13 Sep 2002, Daniel Jacobowitz wrote:

> On Fri, Sep 13, 2002 at 02:12:05PM +0200, Marc Espie wrote:
> > Okay. I'm just going to look at adding a 'syslog' format, then.
> > Rationale: there are precious few portable formats, even in single unix.
> > And format checking is very, very useful in finding some classes of bugs.
> > Now, considering syslog(), you can very easily see that such bugs can be
> > critical very easily, as syslog() tends to be encountered in daemons and
> > such.

I don't think duplicating all the printf format specification with a few
changes is the right interim solution for this for the FSF tree (though of
course you can do it in another tree).  A better interim solution would be
to implement fine-grained warning control (which has many other uses) so
users of -pedantic can disable the warning for %m only.  (This would of
course need to be a version of warning control that allows disabling the
warning just for "warning: ISO C does not support the `%m' printf format"  
and not for similar warnings with other formats than %m specified - one
based on the final message text would work, one based on an assigned
identifier for each message would not.)

> Well, if you have an idea on a syntax for more extensible format
> checking, as Joseph mentioned above, it'd be much nicer if you want
> down that path.  For instance, Linux's printk() would very much like to
> have format checking, but it can't at the moment because it has some
> custom specifiers.

Rather, it would like to have custom specifiers but can't because of the
nonextensibility.  The same applies to GCC's diagnostic functions.

Any good extensible system should allow any of the standard formats to be
specified fully by a user, or a named standard format to be varied
arbitrarily by a user (adding, changing or taking away specifiers and
modifiers and flags, ...).  It also needs not to suffer from closely
exposing GCC's internal data structures so they can't then readily be
changed in future.  (It has been stated
<http://gcc.gnu.org/ml/gcc/2000-12/msg00317.html> that Red Hat has an
extensible format checking implementation, but the description there (I
haven't seen any documentation for it) doesn't make it look satisfactory
and nor does the regular expression approach given in that message as an
alternative seem reasonable in terms of describing the actual structure of
format strings and what's checked.)

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: formats and syslog question

[Jason R Thorpe]

On Fri, Sep 13, 2002 at 06:24:04PM +0200, Marc Espie wrote:

 > Sorry, no idea for a non-icky syntax yet.
 > On the other hand, I consider syslog() to be much more useful than printk,
 > as syslog is universal among unix systems, whereas printk is limited to
 > one single variant.  Maybe Jason R. Thorpe will have further ideas, as
 > I know that NetBSD has a custom version of the printf format for their
 > kernel printf ?

In NetBSD, we actually hacked our in-tree compiler to understand the
kernel printf formats, and made that compiler also -D__KPRINTF_ATTRIBUTE__
so that the headers would know about the presence of that support.

In the mean time, we've been actively removing the custom formats from
the kernel printf, instead using explicit function calls to format the
"weird" things.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

Re: formats and syslog question

[Jonathan Lennox]

Joseph S. Myers wrote:
> Any good extensible system should allow any of the standard formats to be
> specified fully by a user, or a named standard format to be varied
> arbitrarily by a user (adding, changing or taking away specifiers and
> modifiers and flags, ...).  It also needs not to suffer from closely
> exposing GCC's internal data structures so they can't then readily be
> changed in future.

Is the '#pragma varargck' approach used by Plan 9's C compiler
(<http://plan9.bell-labs.com/magic/man2html/1/2c>) at all useful as a
starting point?  It doesn't have all the functionality you describe, but it
allows specifiers and flags to be specified, and lets you define what
argument types the specifiers consume.

Plan 9's printf()-equivalent print() function allows arbitrary format
specifiers to be plugged in, so presumably this approach has been used
pretty heavily and not found too wanting.

-- 
Jonathan Lennox
lennox@cs.columbia.edu

Re: formats and syslog question

[Joseph S. Myers]

On Fri, 13 Sep 2002, Jonathan Lennox wrote:

> Is the '#pragma varargck' approach used by Plan 9's C compiler
> (<http://plan9.bell-labs.com/magic/man2html/1/2c>) at all useful as a
> starting point?  It doesn't have all the functionality you describe, but it
> allows specifiers and flags to be specified, and lets you define what
> argument types the specifiers consume.

It hardly helps here since it doesn't allow anything like "same as printf
but %m is OK with -pedantic".  (Any syntax for GCC clearly shouldn't be
based on #pragma, either; and should be able to cover what the existing
data structures in c-format.c do, except perhaps for
FMT_FLAG_SCANF_A_KLUDGE for which a more orthogonal solution would be
desirable.)

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: formats and syslog question

[Marc Espie]

On Sat, Sep 14, 2002 at 10:44:58AM +0100, Joseph S. Myers wrote:
> On Fri, 13 Sep 2002, Jonathan Lennox wrote:
> 
> > Is the '#pragma varargck' approach used by Plan 9's C compiler
> > (<http://plan9.bell-labs.com/magic/man2html/1/2c>) at all useful as a
> > starting point?  It doesn't have all the functionality you describe, but it
> > allows specifiers and flags to be specified, and lets you define what
> > argument types the specifiers consume.
> 
> It hardly helps here since it doesn't allow anything like "same as printf
> but %m is OK with -pedantic".  (Any syntax for GCC clearly shouldn't be
> based on #pragma, either; and should be able to cover what the existing
> data structures in c-format.c do, except perhaps for
> FMT_FLAG_SCANF_A_KLUDGE for which a more orthogonal solution would be
> desirable.)

I feel that I'm not getting heard, here.

I concur that a generic way to specify formats would be nice.
However, I am not going to do it. And nobody is going to embark on this
right now, it looks like.

*But* there is a concrete need for a syslog() format *right now*.
It is very useful from a security point of view.

And it's completely cross-platform. syslog exists on every unix platform,
and %m is standard for it on most of it (since it's specified in Single
Unix).

Compare this to all the other samples of functions which were given that
are much more exotic (linux's printk INCLUDED).

How does it hurt to have this added in the FSF tree ?
Okay, it's bloat.

Wow. What bloat. An extra entry in a format table and three pesky lines of
code.

Give me a single example of a function that understands formats that's not
supported yet and that is as wide-spread as syslog...

Granted, I can do this in my tree (and I will), but come on, this can be
of use to everyone right now.

Why wait for years until someone finally embarks on specifying a format
language ? which is going to be either highly esoteric, OR a very large
piece to add to gcc yet...

Re: formats and syslog question

[Joseph S. Myers]

On Sat, 14 Sep 2002, Marc Espie wrote:

> *But* there is a concrete need for a syslog() format *right now*.
> It is very useful from a security point of view.
> 
> And it's completely cross-platform. syslog exists on every unix platform,
> and %m is standard for it on most of it (since it's specified in Single
> Unix).
> 
> Compare this to all the other samples of functions which were given that
> are much more exotic (linux's printk INCLUDED).

For most users, the use of -pedantic is fairly exotic - and they can
ignore this particular warning for syslog if they do use -pedantic.  
(It's a warning, not a pedwarn, so does not become an error with
-pedantic-errors.)  I've suggested warning control as a reasonable
medium-term (3.4 - and a syslog format wouldn't be appropriate to add at
this development stage, either) solution.

> How does it hurt to have this added in the FSF tree ?
> Okay, it's bloat.
> 
> Wow. What bloat. An extra entry in a format table and three pesky lines of
> code.

Duplication of a table and the consequent risk of divergence between the
two similar but different tables, both of which now need to be maintained.

> Give me a single example of a function that understands formats that's not
> supported yet and that is as wide-spread as syslog...
> 
> Granted, I can do this in my tree (and I will), but come on, this can be
> of use to everyone right now.

syslog is supported, and has been for a long time, by the printf format;
there's just the warning for the limited number of users using -pedantic.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: formats and syslog question

[Marc Espie]

On Sat, Sep 14, 2002 at 11:45:50AM +0100, Joseph S. Myers wrote:
> Duplication of a table and the consequent risk of divergence between the
> two similar but different tables, both of which now need to be maintained.

This can be handled easily, by not using cut&paste but programming the copy 
instead. Acceptable ?

> syslog is supported, and has been for a long time, by the printf format;
> there's just the warning for the limited number of users using -pedantic.

...which kills -Wall -pedantic -Werror, which are flags you may want to
use for security stuff.

(and even without -Werror, extra warnings are likely to hide deeper
problems).

Re: formats and syslog question

[Joseph S. Myers]

On Sat, 14 Sep 2002, Marc Espie wrote:

> On Sat, Sep 14, 2002 at 11:45:50AM +0100, Joseph S. Myers wrote:
> > Duplication of a table and the consequent risk of divergence between the
> > two similar but different tables, both of which now need to be maintained.
> 
> This can be handled easily, by not using cut&paste but programming the copy 
> instead. Acceptable ?

I suggest the alternative syntax
__attribute__ ((__format__(__printf__, 2, 3, __nopedantic__)))
to disable all pedantic checking of that format applied to that function, 
which has some potential of other uses.  (Clearly a syslog format 
shouldn't give pedantic warnings for %C or %S or the ' flag or $ formats, 
as well as %m; but if treated as a separate format from printf it 
shouldn't give pedantic warnings for other extensions either since it's 
none of -pedantic's business to warn for features outside a standard other 
than ISO C/C++.  Treating syslog formats as entirely separate from the 
existing four types supported implies -pedantic should not be concerned 
with them any more than it is with GNU extensions to strfmon formats at 
present.)

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: formats and syslog question

[Fergus Henderson]

On 14-Sep-2002, Joseph S. Myers <jsm28@cam.ac.uk> wrote:
> 
> For most users, the use of -pedantic is fairly exotic -

If that is the case, it is a pity.
We should not do anything to encourage that state of affairs.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: formats and syslog question

[Gabriel Dos Reis]

Fergus Henderson <fjh@cs.mu.OZ.AU> writes:

| On 14-Sep-2002, Joseph S. Myers <jsm28@cam.ac.uk> wrote:
| > 
| > For most users, the use of -pedantic is fairly exotic -
| 
| If that is the case, it is a pity.

I think it is.  At least from feebacks I get here and there.

Indeed, why such a pedantic name for a flag that just asks the
compiler to do thr right thing?

| We should not do anything to encourage that state of affairs.

By making -pedantic the default?

-- Gaby

Re: formats and syslog question

[Gabriel Dos Reis]

"Joseph S. Myers" <jsm28@cam.ac.uk> writes:

| On 14 Sep 2002, Gabriel Dos Reis wrote:
| 
| > |  | `-fpermissive'
| > |  |      Downgrade messages about nonconformant code from errors to
| > |  |      warnings.  By default, G++ effectively sets `-pedantic-errors'
| > |  |      without `-pedantic'; this option reverses that.  This behavior and
| > |  |      this option are superseded by `-pedantic', which works as it does
| > |  |      for GNU C.
| > 
| > This doesn't make sense.  What -pedantic-errors does is to turn
| > warnings generated by -pedantic into errors.
| 
| The intended meaning of this documentation is of course that mandatory
| pedwarns are errors by default for C++.  The problem is how to express
| clearly to the user four classes of warnings with respect to -pedantic,
| mandatory warning()s, mandatory pedwarn()s, pedwarn()s if pedantic and
| warning()s if pedantic, all four of which occur.

OK, but at least the current wording is confusing since specifying
-pedantic-errors doesn't give the same behaviour as the default.

-- Gaby

Re: formats and syslog question

[Joseph S. Myers]

On 14 Sep 2002, Gabriel Dos Reis wrote:

> |  | `-fpermissive'
> |  |      Downgrade messages about nonconformant code from errors to
> |  |      warnings.  By default, G++ effectively sets `-pedantic-errors'
> |  |      without `-pedantic'; this option reverses that.  This behavior and
> |  |      this option are superseded by `-pedantic', which works as it does
> |  |      for GNU C.
> 
> This doesn't make sense.  What -pedantic-errors does is to turn
> warnings generated by -pedantic into errors.

The intended meaning of this documentation is of course that mandatory
pedwarns are errors by default for C++.  The problem is how to express
clearly to the user four classes of warnings with respect to -pedantic,
mandatory warning()s, mandatory pedwarn()s, pedwarn()s if pedantic and
warning()s if pedantic, all four of which occur.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: formats and syslog question

[Gabriel Dos Reis]

Fergus Henderson <fjh@cs.mu.oz.au> writes:

| On 14-Sep-2002, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
| > Fergus Henderson <fjh@cs.mu.OZ.AU> writes:
| > | Same is true for C++, where -pedantic-errors is the default,
| > 
| > I don't think that is true.
| 
| The GCC 3.2 documentation for -fpermissive says that it is:
| 
|  | `-fpermissive'
|  |      Downgrade messages about nonconformant code from errors to
|  |      warnings.  By default, G++ effectively sets `-pedantic-errors'
|  |      without `-pedantic'; this option reverses that.  This behavior and
|  |      this option are superseded by `-pedantic', which works as it does
|  |      for GNU C.

This doesn't make sense.  What -pedantic-errors does is to turn
warnings generated by -pedantic into errors.

   @item -pedantic-errors
   @opindex pedantic-errors
   Like @option{-pedantic}, except that errors are produced rather than
   warnings.

Therefore, if -pedantic-errors is set then -pedantic is set except that
what should be warnings are reported as errors.

So, the documention of -fpermissive is incorrect and inconsistent with
the rest of the documentation.

| So if it's not, then the behaviour doesn't match the documentation,
| and IMHO the best way to fix it would be to change the behaviour
| so that -pedantic-errors really is the default.

In this case, it is the documentation of -fpermissive that doesn't
match behaviour.  I'm not sure the best way to fix it is that you're
proposing.  What you're proposing doesn't reflect the current
behaviour. 

-- Gaby

Re: formats and syslog question

[Fergus Henderson]

On 14-Sep-2002, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> Fergus Henderson <fjh@cs.mu.OZ.AU> writes:
> | Same is true for C++, where -pedantic-errors is the default,
> 
> I don't think that is true.

The GCC 3.2 documentation for -fpermissive says that it is:

 | `-fpermissive'
 |      Downgrade messages about nonconformant code from errors to
 |      warnings.  By default, G++ effectively sets `-pedantic-errors'
 |      without `-pedantic'; this option reverses that.  This behavior and
 |      this option are superseded by `-pedantic', which works as it does
 |      for GNU C.

So if it's not, then the behaviour doesn't match the documentation,
and IMHO the best way to fix it would be to change the behaviour
so that -pedantic-errors really is the default.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: formats and syslog question

[Gabriel Dos Reis]

Fergus Henderson <fjh@cs.mu.OZ.AU> writes:

| On 14-Sep-2002, Robert Dewar <dewar@gnat.com> wrote:
| > > > For most users, the use of -pedantic is fairly exotic -
| > > 
| > > If that is the case, it is a pity.
| > > We should not do anything to encourage that state of affairs.
| > 
| > 
| > Well of course the name "pedantic" quite deliberately expresses the opposite
| > viewpoint. In the case of GNAT, you get strictly the standard language (with
| > allowable pragma/attribute extensions), and if you want real language
| > extensions you have to use an option -gnatX.
| 
| Same is true for C++, where -pedantic-errors is the default,

I don't think that is true.  I just did a grep flag_pedantic under cp/
and I found:

   cvt.c:    if (flag_pedantic_errors)
   decl.c:    flag_pedantic_errors = 1;
   decl.c:      int old_flag_pedantic_errors = flag_pedantic_errors;
   decl.c:      pedantic = flag_pedantic_errors = 1;
   decl.c:      flag_pedantic_errors = old_flag_pedantic_errors;
   decl.c:       if (flag_pedantic_errors)


| and you need -fpermissive to disable it.

Well, -fpermissive lets us parse some outdated and antiquicated
constructs, and it is off by default.  But we don't have
-pedantic-errors by default.

[...]

| But I do object to people arguing that we should not mind if `-pedantic'
| results in spurious warnings for Posix programs, because `-pedantic'
| is "exotic"!

But, "-pedantic" is *perceived* exotic by its very name -- and it is
all about perception :-)

-- Gaby

Re: formats and syslog question

[Robert Dewar]

> But I do object to people arguing that we should not mind if `-pedantic'
> results in spurious warnings for Posix programs, because `-pedantic'
> is "exotic"!

Yes, indeed, I agree that correct operation in -pedantic mode, including
the avoidance of spurious warnings, is a reasonable requirement.

Re: formats and syslog question

[Fergus Henderson]

On 14-Sep-2002, Robert Dewar <dewar@gnat.com> wrote:
> > > For most users, the use of -pedantic is fairly exotic -
> > 
> > If that is the case, it is a pity.
> > We should not do anything to encourage that state of affairs.
> 
> 
> Well of course the name "pedantic" quite deliberately expresses the opposite
> viewpoint. In the case of GNAT, you get strictly the standard language (with
> allowable pragma/attribute extensions), and if you want real language
> extensions you have to use an option -gnatX.

Same is true for C++, where -pedantic-errors is the default,
and you need -fpermissive to disable it.

> But for C, the general philosophy of GCC has been to encourage the use of
> GNU C extensions, and there is probably no point in rediscussing that
> viewpoint since nothing has really changed.

I'm not trying to argue that `-pedantic' be renamed, or that it be
made the default for C.  Those arguments have already been made and
lost, and it is not (yet ;-) time to re-open that debate.

But I do object to people arguing that we should not mind if `-pedantic'
results in spurious warnings for Posix programs, because `-pedantic'
is "exotic"!

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: formats and syslog question

[Robert Dewar]

> > For most users, the use of -pedantic is fairly exotic -
> 
> If that is the case, it is a pity.
> We should not do anything to encourage that state of affairs.


Well of course the name "pedantic" quite deliberately expresses the opposite
viewpoint. In the case of GNAT, you get strictly the standard language (with
allowable pragma/attribute extensions), and if you want real language extensions
you have to use an option -gnatX.

But for C, the general philosophy of GCC has been to encourage the use of
GNU C extensions, and there is probably no point in rediscussing that viewpoint
since nothing has really changed.