Re: Expand the definition of gnu89 slightly

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

On Tue, 4 Feb 2003, Neil Booth wrote:

> Is there a good rationale for not even warning in c89 without -pedantic?
> We seem to be quite arbitrary on these points, and IMO at least we are
> far too quiet by default.

The rules were established long ago (probably by RMS) and are documented
("The -ansi option does not cause non-ISO programs to be rejected
gratuitously.").  Having -ansi -pedantic-errors the default might make
sense for a new compiler, but not now for GCC.  (In fact -Wall by default
would be tempting, given the number of bug reports where -Wall would have
shown the problem in the original code.)  But users wouldn't like either
of these being default in general.  (-std=c89/-std=c99 -pedantic-errors
implements the standard and is tested by the standard tests.  The default
mode accommodates what many users want to a much greater extent.)

> I think we should warn unconditionally in C89; I even view that as
> lenient.  In my parser, it's a hard error, for example.
>
> I don't think that "it's legal in C99" or "we can compile successfully
> anyway" are good reasons to require -pedantic.

I'm happy for nonsense code (not part of any C standard and not a
documented extension) to generate unconditional hard errors.  Prime
examples of this are various cases of stray semicolons or missing
semicolons that are accepted (with or without mandatory pedwarn; the case
of label at end of compound statement has been explicitly deprecated for a
while), writing into const lvalues (which users expect to be an error) and
returning a non-void value from functions returning void (returning a void
value is still an extension, but makes more sense).

Duplicate qualifiers would have counted as nonsense code, until C99
allowed them, which makes treating them as an extension in C90 mode (in
line with general treatment of C99 features) make more sense.  I presume
the motivation of this patch was that duplicate qualifiers appear (via
typedef) in conjunction with macros used in the Linux kernel.

The one significant C99 feature not allowed in C90 mode is "for (int i =
0; i < 10; i++)", because of the need in that case for the new C99 scopes.
Other C99 features generally make sense as extensions to C90.

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