Re: The problems in comp.lang.c

Paulo Jorge de O. C. de Matos wrote:

santosh <santosh.k83@xxxxxxxxx> writes:

santosh wrote:
Paulo Jorge de O. C. de Matos wrote:

<snip>

I guess these are in fact, the things I use the most from C99. The
other stuff might be useful to others. I even inquired the gcc
people why C99 is so poorly [in ~10 years they still miss a couple
of features] implemented. Their reply was ... interesting but
not as clear as one would wish:
http://gcc.gnu.org/ml/gcc-help/2008-03/msg00221.html

Interesting.

And to follow up, Paulo's respondent seems to be implying pretty
strongly that a reason for gcc's slow implementation of C99 (and for
many other implementations as well) is that C is proving to be an
ill-designed language to extend easily.


Although I don't know much about compilers, I've had the opportunity
of implementing a software verifier based on SAT techniques inside
gcc. From what I have seen gcc is a pretty big beast and quite
complex. I would even go to the point of saying that the problem might
not be [only] C as a language but GCC that was not prepared to be
extended to this point and many things start to conflict with each
other resulting in bugs and missing features. For an example, check:
http://www.nabble.com/Inline-functions-in-C99-td15789469.html

This is however, just my intuition. I have no concrete information or
proof that the problem with the C99 implementation lies with GCC.

[snip]

Okay this is an interesting view and yes, from what little I have seen
of gcc's code, it is very complex. But if the complexity of the code
were one reason for difficulty in extending gcc's feature set, then one
would presume that g++ would suffer as badly, if not more, since C++ is
a much more diffcult language to write a compiler for. However it may
be that g++ has had the benefit of a better design, perhaps learning
from some of the problems faced by gcc.

.

Relevant Pages

  • Re: The problems in comp.lang.c
    ... strongly that a reason for gcc's slow implementation of C99 (and for ... My more general experience is that it depends on whether you designed your implementation to be easy to easy to extend. ... Jacob internally using operator overloading is actually an example of designing the implementation to be easy to extend in certain areas! ... I suspect the reason that gcc and a lot of other C compilers might not be designed to be easy to extend is because there was not seen to be a reason to do so after C89 because the language was then standardised and so not subject to change! ...
    (comp.lang.c)
  • Re: swap() function without tmp
    ... GCC, the GNU Compiler Collection, implements a conforming C89 ... >non-conforming attempt at a C99 compiler, some of which is accomplished by ... >simply not giving warnings or errors for traditional GNU C extensions. ... which is where most of work of upgrading from C89 to C99 goes. ...
    (comp.lang.c)
  • 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: Not quite standard... but socially acceptable
    ... gcc will NOT compile c99. ... standard; there are a number of features that are not implemented. ... aka C95) is the only way to cause gcc to conform ... Note also that C90 is nearly a subset of C99, ...
    (comp.lang.c)
  • Re: A simple parser
    ... In order to get gcc to support those features, one must invoke it in a ... It has no mode in which it's as conforming to C99. ... The only way to get gcc to accept those features ...
    (comp.lang.c)