From: "Dr. David Kirkby" <david.kirkby@onetel.net>
To: Andrew Haley <aph@redhat.com>, gcc-help@gcc.gnu.org
Subject: Re: Why is gcc going to default to "GNU dialect of ISO C99?"
Date: Wed, 10 Feb 2010 17:45:00 -0000 [thread overview]
Message-ID: <4B72EC1D.8060706@onetel.net> (raw)
In-Reply-To: <4B72E628.4000904@redhat.com>
Andrew Haley wrote:
> On 02/10/2010 04:44 PM, Dr. David Kirkby wrote:
>> According to
>>
>> http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#C-Dialect-Options
>>
>> -std=foobar
>>
>>
>> `gnu9x'
>> GNU dialect of ISO C99. When ISO C99 is fully implemented in GCC,
>> this will become the default. The name `gnu9x' is deprecated.
>>
>> I really can not understand the logic of this. Why not default to ISO
>> C99 and let people enable GNUisms if they wish to? Then code should be
>> more portable across different compilers. With the GNUisms allowed by
>> default, it will make porting code more difficult to other stricter
>> compilers.
>
> This reasoning would make perfect sense if the primary goal of gcc's
> users was to write code to be ported to other compilers.
I thought gcc's primary aim was to be a *C* compiler. That would suggest to me
that enabling GNU extensions should not be the default, but an option.
A lot of bugs are often discovered in code by testing on multiple compilers and
multiple platforms. What one compiler misses, another finds. I could point you
to various cases where the Sun compiler has rejected erroneous code that gcc has
permitted. I'm sure you could no doubt find counter examples too.
By generating code that should build with other compilers, problems can be
detected more easily.
> However,
> many of GNU C's extensions are very useful, so it makes sense to have
> them available by default. (Having said that, many of GNU C's
> extensions are part of C99 anyway, so the difference is smaller than
> with C89.)
Personally I feel this is a bad decision, but I'm not a gcc developer.
Dave
next prev parent reply other threads:[~2010-02-10 17:26 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-10 17:00 Dr. David Kirkby
2010-02-10 17:26 ` Andrew Haley
2010-02-10 17:45 ` Dr. David Kirkby [this message]
2010-02-10 18:07 ` Alfred M. Szmidt
2010-02-10 19:25 ` Dr. David Kirkby
2010-02-10 20:59 ` Kevin P. Fleming
2010-02-10 18:39 ` Andrew Haley
2010-02-11 2:46 ` Ian Lance Taylor
2010-02-11 2:40 Dennis Clarke
2010-02-11 9:43 ` Alfred M. Szmidt
2010-02-11 12:00 ` Alexey Salmin
[not found] ` <C79952E6.1947E%eljay@adobe.com>
2010-02-11 13:48 ` Alexey Salmin
[not found] ` <C79973C1.194A3%eljay@adobe.com>
2010-02-11 14:58 ` Alexey Salmin
2010-02-11 15:11 ` John (Eljay) Love-Jensen
2010-02-12 5:32 ` Patrick Horgan
2010-02-11 13:44 Dennis Clarke
2010-02-11 14:00 ` Alexey Salmin
2010-02-11 14:14 Dennis Clarke
2010-02-11 14:42 ` Alexey Salmin
2010-02-11 14:50 Dennis Clarke
2010-02-11 17:14 Dennis Clarke
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=4B72EC1D.8060706@onetel.net \
--to=david.kirkby@onetel.net \
--cc=aph@redhat.com \
--cc=gcc-help@gcc.gnu.org \
/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).