Re: What's the deal with C99?

Keith Thompson wrote:

santosh <santosh.k83@xxxxxxxxx> writes:
Keith Thompson wrote:
"Bartc" <bc@xxxxxxxxxx> writes:

I've looked at the differences in C99 according to the Wikipedia C
article.

It doesn't look like that much to add to C90.

So why the problem with creating compilers for it, is it
motivation?

<snip>

When ISO introduced the C99 standard, the situation was different.
The C programming community *already* had a standardized language,
and it worked well enough for most purposes.

Compiler vendors aren't in the business of conforming to standards,
as
much as we might like that to be the case. They're in the business
of meeting the demands of their customers (and that applies to
freeware
compilers such as gcc as well as to commercial compilers). There
wasn't nearly as great a demand for C99 conformance as there had
been for C89/C90 conformance.

If, as you say, most of the C programming community had a standard
with which they were well pleased and the compiler vendors were
pleased that most of their user base was pleased, why was there
another standard at all? Who were the main driving force behind C99?
I was informed that a section of compiler vendors, users, and other
organisations pressed WG14 for inclusion of greater range of
mathematical features, so that they might replace more of their
Fortran code with C, and this was one of the chief reasons for WG14
to come out with C99. Is this your take on the matter too?

Hmm. I'm not familiar enough with the history to comment on that.

Your account seems to imply that vendors demanded these new features,
and then when they got them in a new standard, they declined to
implement that new standard. Is that really what happened?

Well this is what I gathered from various posts here and in comp.std.c:
that it was a fairly small group that lobbied for inclusion of complex
arithmetic, VLAs, fenv.h and tgmath.h.

It does explain (if it is true) why the features listed above are among
the ones that are least widely implemented.

And what of the next, C1x standard in discussion?
Can the community and WG14 ensure that, this time at least, only
features that have the support of a broad swathe of users and
compiler vendors would be added? Should C continue to be a minimalist
general purpose language or should it include specialised support for
those domains that WG14 thinks would constitute the mainstay of C in
the future, at the risk of the language faller further into disuse on
desktops?

In my opinion, the best chance for the survival of C and for
widespread support for any new standard (note that these are two
different, but related, things) is for C to remain fairly minimalist.
If that makes it a niche language, rather than the universal
programming language it seemed to be a few decades ago, that's not
necessarily a bad thing. (I'm willing to radically change this
opinion at the slightest provocation.)

Maybe C should follow what ISO did for Pascal and include features that
are (or might be) poorly implemented into an "extended" standard for
the language, with the core standard being more or less frozen around
C95?

Then nearly all implementors could have the satisfaction of labelling
their products "fully conforming to the Core C Standard" while
ambitious vendors could implement "the extended C Standard". This way
programmers who want their source to be maximally portable could stick
to the core standard while simultaneously those who want to use widely
implemented but not ubiquitous features could write to the extended
standard.

Features like VLAs, complex arithmetic, fenv.h etc. could be moved to
the extended standard and widely available things like APIs for
traversing directories etc., could be added to it, without
necessitating that either all implementations implement them or risk
being labelled "non-conforming".

<snip humour>

.

Relevant Pages

  • Re: C++ danger to break due to its weight, fragmentation danger - C++0x
    ... Also not all of the new features will be ... libraries for the standard on the way which are optional. ... extensions to the C++ compiler. ...
    (comp.lang.cpp)
  • Re: Teaching new tricks to an old dog (C++ -->Ada)
    ... > the standard language. ... Or did they just implemented some 80% of the new features? ... there was a fully compiant C compiler available. ...
    (comp.lang.ada)
  • Re: Teaching new tricks to an old dog (C++ -->Ada)
    ... > the standard language. ... Or did they just implemented some 80% of the new features? ... there was a fully compiant C compiler available. ...
    (comp.lang.cpp)
  • Re: future C standards
    ... I have been working for YEARS trying to implement all features of the ... C99 standard. ... a front end presumably is not a full compiler. ... gcc is not a fully conforming C99 ...
    (comp.std.c)
  • Re: Is C99 the final C? (some suggestions)
    ... > that someone will try compile their stuff on an old compiler. ... > because the ANSI standard obsoleted them, and everyone picked up the ANSI ... fixed by using another language. ... >>are multiplying two expressions of the widest type supported by your ...
    (comp.lang.c)