Re: c/5957: gcc accepts C99-only code even when -std=c89 arg used

Re: c/5957: gcc accepts C99-only code even when -std=c89 arg used

[Craig Rodrigues]

The following reply was made to PR c/5957; it has been noted by GNATS.

From: Craig Rodrigues <rodrigc@attbi.com>
To: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
   nobody@gcc.gnu.org, jason-gccprs@molenda.com, jsm28@cam.ac.uk
Cc:  
Subject: Re: c/5957: gcc accepts C99-only code even when -std=c89 arg used
Date: Sat, 20 Apr 2002 13:29:14 -0400

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5957
 
 
 On 14 Mar 2002 jason-gccprs@molenda.com wrote:
 
  > When gcc is given a source file like the following:
  >
  > #include <stdio.h>
  > int main () { puts ("hi"); int f; }
  >
  > which is invalid in ISO C89 or the 1994 Amendment, it will accept the
  > code even if -std=c89 is given on the command line.  If -pedantic is
  > added, it will issue a pedwarn,
 
 This decision was made long ago (when RMS was maintainer) and documented,
 and I don't think it's open to change it now.
 
         The @option{-ansi} option does not cause non-ISO programs to be
         rejected gratuitously.  For that, @option{-pedantic} is required in
         addition to @option{-ansi}.  @xref{Warning Options}.
 
  > but I'd argue that this is not sufficient.  If I pass -std=c89 to gcc,
  > I expect that the code which compiles will also compile for Bob down
  > the hall, who is stubborn and refuses to upgrade beyond gcc 2.95.  I
  > can understand that gcc can't provide a genuinely ISO C89 environment
  > when C99-only headers may be present, but it should be able to handle
  > this one.
 
 You should expect (from the manual) that C89 code is correctly compiled,
 not that other code is rejected - -pedantic (or -pedantic-errors) is for
 rejecting code.  I don't think we've ever claimed to provide a "warn if
 2.95 doesn't support this" feature other than running 2.95 itself on the
 code.
 
 (Before gnu99 mode becomes the default, there will, however, be a -Wc89
 option added to warn about C99 features not in C89.)
 
  > Inside gcc, the flag_isoc94, flag_isoc99 variables which one might try
  > to use to catch this error, seem to be intended only to indicate
  > additional capabilities that should be recognized.  i.e. I don't see a
  > way in c-parse.in to detect that the user is requesting a specifically
  > restricted set of C constructs with the current set of flags.
 
 -pedantic is the way to request a restricted set of C constructs.  That
 the C++ front end is not compiled with -pedantic, and so mixed
 declarations and code sometimes find their way into it though
 cross-compilers should be buildable with 2.95, is a separate issue; I
 think the C++ front end should be restricted to use C89 only, given the
 desirability of being able to move code from it to the C front end.
 
  > gcc 3.1's behavior in this case by default is also confusing.  I guess
  > gcc is in "g89" mode by default, so if you need to add "-std=c99" to
  > explicitly put yourself in ISO C99 mode.  But you can use C99 features
  > like variable-decls-after-statements-in-a-block in the "g89" mode
  > (which wouldn't have worked with 2.95's g89 mode).
 
 gnu89 is C89 plus all extensions to C89 that make sense as extensions to
 C89.  Such extensions include some C99 features, such as mixed
 declarations and code.  It's not gnu2.95.  (gnu89 is in some cases a
 compatibility mode that accepts features not compatible with C99, that are
 or will be rejected in c99 and gnu99 modes, e.g. certain uses of compound
 literals, and will maintain the old inline semantics when C99 ones are
 implemented.  But it isn't a mode for testing whether code will run with a
 given old version.)
 
 The documentation for -pedantic elaborates on what -pedantic does in gnu89
 and gnu99 modes.
 
 -- 
 Joseph S. Myers
 jsm28@cam.ac.uk
 
 
 

Re: c/5957: gcc accepts C99-only code even when -std=c89 arg used

[neil]

Synopsis: gcc accepts C99-only code even when -std=c89 arg used

State-Changed-From-To: open->closed
State-Changed-By: neil
State-Changed-When: Fri Mar 29 00:50:40 2002
State-Changed-Why:
    This is not a bug, it's the meaning of the options, though you may disagree with it.
    If you want a hard error, you need -pedantic-errors.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5957

c/5957: gcc accepts C99-only code even when -std=c89 arg used

[jason-gccprs]

>Number:         5957
>Category:       c
>Synopsis:       gcc accepts C99-only code even when -std=c89 arg used
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Mar 13 19:06:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Jason Molenda
>Release:        gcc-3_1-branch
>Organization:
>Environment:

>Description:
When gcc is given a source file like the following:

#include <stdio.h>
int main () { puts ("hi"); int f; }

which is invalid in ISO C89 or the 1994 Amendment, it will accept the code even if -std=c89 is given on the command line.  If -pedantic is added, it will issue a pedwarn,

ISO C89 forbids mixed declarations and code

but I'd argue that this is not sufficient.  If I pass -std=c89 to gcc, I expect that the code which compiles will also compile for Bob down the hall, who is stubborn and refuses to upgrade beyond gcc 2.95.   I can understand that gcc can't provide a genuinely ISO C89 environment when C99-only headers may be present, but it should be able to handle this one.

Inside gcc, the flag_isoc94, flag_isoc99 variables which one might try to use to catch this error, seem to be intended only to indicate additional capabilities that should be recognized.  i.e. I don't see a way in c-parse.in to detect that the user is requesting a specifically restricted set of C constructs with the current set of flags.

gcc 3.1's behavior in this case by default is also confusing.  I guess gcc is in "g89" mode by default, so if you need to add "-std=c99" to explicitly put yourself in ISO C99 mode.  But you can use C99 features like variable-decls-after-statements-in-a-block in the "g89" mode (which wouldn't have worked with 2.95's g89 mode).
>How-To-Repeat:

>Fix:
Recognize in c-decl.c when the user is explicitly asking for c89 or c94 mode, and issue an error() when c99-specific constructs are used in the source.
>Release-Note:
>Audit-Trail:
>Unformatted: