public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: Craig Rodrigues <rodrigc@attbi.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, Subject: Re: c/5957: gcc accepts C99-only code even when -std=c89 arg used Date: Sat, 20 Apr 2002 10:36:00 -0000 [thread overview] Message-ID: <20020420173601.12096.qmail@sources.redhat.com> (raw) 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
next reply other threads:[~2002-04-20 17:36 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2002-04-20 10:36 Craig Rodrigues [this message] -- strict thread matches above, loose matches on Subject: below -- 2002-03-29 0:50 neil 2002-03-13 19:06 jason-gccprs
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=20020420173601.12096.qmail@sources.redhat.com \ --to=rodrigc@attbi.com \ --cc=gcc-prs@gcc.gnu.org \ --cc=nobody@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: linkBe 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).