Re: Why the C programming language book was never updated past C89?

From	Richard Heathfield <rjh@cpax.org.uk>
Newsgroups	comp.lang.c
Subject	Re: Why the C programming language book was never updated past C89?
Date	2015-02-05 13:52 +0000
Organization	go, ion artisan!
Message-ID	<mavsi2$ibc$1@dont-email.me> (permalink)
References	<5478fb0c$0$22069$426a74cc@news.free.fr> <54d34897$0$13647$882e7ee2@usenet-news.net> <maviu4$dht$1@dont-email.me> <mavqib$ah7$1@dont-email.me>

Show all headers | View raw

On 05/02/15 13:18, David Brown wrote:
> On 05/02/15 12:08, Richard Heathfield wrote:
>> [...] C99 was a ghastly mess, and they did not
>> wish to be associated with it.
>>
>
> You are going to have to justify that last statement.

Delighted, my dear fellow! :-)

> Apart from a few
> technical details of floating point support, and perhaps some library
> choices, C99 seems to me to be a solid improvement over C90.  Of the
> list at <http://en.wikipedia.org/wiki/C99#Design>, which features of C99
> make it a "ghastly mess" ?

Thanks for the link. It makes itemisation a lot easier.

1) inline functions - a completely unnecessary addition to the language. 
Implementations were already free to make functions inline, and they 
don't have to listen to you anyway. In that respect, it's no better than 
register.

2) intermingled declarations and code - makes code easier to write, but 
harder to read. In my view, easy-to-read takes precedence.

3) long long int et al: utterly unnecessary. Implementations were 
already free to make long int 64 bits (or more). We already had a type 
menagerie, but now we have a type safari park. There's this enormous 
herd of types, just roaming around the place looking for victims.

4) variable-length arrays: totally unnecessary, and introduces an 
undetectable point of failure.

5) flexible array members: in my view a rather pointless change; if they 
were going to codify what lots of people were already doing, it might 
have been a good idea to codify it in the way that lots of people were 
already doing. But it doesn't bother me that it's there, since lots of 
people were already doing that anyway.

6) one-line comments: unnecessary, since we already had
    /* one-line comments */
and introduces a particularly hard-to-find bug. A friend of mine working 
at Oracle once complained to me that they'd spent days trying to find 
out why bar() wasn't being called, in:

   foo(); // does the foo thing in c:\path\morepath\bin\
   bar();

(The code is of course invented, but it accurately mirrors the bug.) And 
it took them *days* to find it. At Oracle, that adds up to a fair amount 
of lost money.

7) new library functions: well, I'm not going to bitch too much about 
these, but I don't personally feel the need to use any of them, and I'm 
hard-pressed to even think of a name or two. snprintf, yeah, I remember 
that one.

8) new headers: naturally, I see no need for these, given the above.

9) type-generic math: not something I personally have any need for, but 
I can see why it might be useful.

10) improved support for IEEE floating-point: was this actually 
necessary? And did it really have to take twenty pages to define it? One 
of the best things about the ISO C standard was the brevity of the text, 
but C99 adds over 200 pages to the document, almost doubling its size.

11) designated initialisers: ugly syntax to solve a non-problem.

There we go. Plenty there for you to yell at me about. :-)

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

Thread

csiph-web