Re: A simple parser

Mark McIntyre <markmcintyre@xxxxxxxxxxx> writes:
On Sun, 15 Oct 2006 23:36:08 +0000, in comp.lang.c , Richard
Heathfield <invalid@xxxxxxxxxxxxxxx> wrote:
Richard said:
[..]
Err, for the C99 features I use (primarily localised declarations),
gcc. I thought I mentioned that?

In order to get gcc to support those features, one must invoke it in a
non-conforming mode.

This is false and you know it.

No, he's right on this point.

gcc has a mode in which it's reasonably (but not perfectly) conforming
to C90. It has no mode in which it's as conforming to C99.

gcc supports "//" comments and mixed declarations and statements
either as gcc-specific extensions, or as part of its incomplete C99
support. The only way to get gcc to accept those features
(non-standard in C90, standard in C99) is to invoke it in a mode that
does not conform to any standard. Such a mode causes it to accept
*other* extensions as well; in other words, it will then fail to
diagnose a number of non-C90 constructs.

If gcc allowed you to accept "//" comments and mixed declarations and
statements while still rejecting all other non-C90 extensions, it
might be a different story. If there were a list of C99 features that
are supported by all current C compilers (a least common denominator
bigger than strict C90 but smaller than full C99), *and* a way to
invoke gcc so that it accepts those features and no others, then it
might be possible to write portable code that uses some of C99. But,
as far as I know, gcc's command-line options do not allow that kind of
fine-grained control.

Many (most?) other C compilers also support some C99 features, but not
necessarily the same set that gcc supports. If I compile my code with
gcc, using a mode in which it accepts "//" comments, it will fail to
diagnose accidental use of C99 features that might not be supported by
some other compiler. The *only* reliable way to guarantee maximal
portability is to invoke gcc is strict C90-conforming mode; any code
that passes that (barring compiler bugs) should be portable to any
C90-conforming implementation. (Well, that's not *quite* true; I
don't think gcc will complain about "int i = 33000;".)

Is there a table somewhere showing exactly which C99 features are
supported by which implementations? I know that such a list exists
for gcc, but a table for multiple implementations could give us a
better idea of what's really portable. And if such a table existed
and were generally known, it just might advance the goal of C99
conformance across the board.

--
Keith Thompson (The_Other_Keith) kst-u@xxxxxxx <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
.

Relevant Pages

  • Re: math.nroot [was Re: A brief question.]
    ... > so before VC 7.1 was released (C99 ain't exactly new anymore). ... > support _some_ way to get at this stuff. ... This includes gcc before C99 ... > and fenv.h -- if the platforms represented in fpectlmodule.c were ...
    (comp.lang.python)
  • Re: function -> macro
    ... GCC and other C compilers now support many of the new features ... GCC, despite its extensive C99 support, is still not a completely ...
    (comp.lang.c)
  • Re: function -> macro
    ... GCC and other C compilers now support many of the new features of C99. ...
    (comp.lang.c)
  • Re: function -> macro
    ... GCC and other C compilers now support many of the new features of C99. ...
    (comp.lang.c)
  • Re: Why not add namespace feature into standard C?
    ... He's saying that the maintainers of gcc haven't done much to add C99 ... features to their compiler, even those features that don't conflict ...
    (comp.lang.c)