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

From	Robert Wessel <robertwessel2@yahoo.com>
Newsgroups	comp.lang.c
Subject	Re: Why the C programming language book was never updated past C89?
Message-ID	<o9e7dahd48s8mcmeintsucfm4vthpbcf9l@4ax.com> (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> <mavsi2$ibc$1@dont-email.me>
Organization	Forte - www.forteinc.com
Date	2015-02-05 13:04 -0600

Show all headers | View raw

On Thu, 05 Feb 2015 13:52:35 +0000, Richard Heathfield
<rjh@cpax.org.uk> wrote:

>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.

At best a minor item.  OTOH, I still find myself needing to hint to
compilers that a function should be inlined, although I admittedly
find myself needing to use the local version of "force_inline" more
frequently.

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

Reducing the scope of variables is a good thing, particularly if some
routines get a bit longer than ideal.

>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.

A type known to be at least 64 bits was utterly desperately needed.
Since changing the definition of long to that would have been
impossible, long long seems a reasonable choice, although the actual
name doesn't matter.

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

I'm not sure about VLAs, they would appear to solve problems I've had,
I've never had the opportunity to use than (thanks MS!), but
uncatchable stack overflows have always been possible.

>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 */

/*...*/ comments are an abomination.  You may feel differently, of
course.  But you'd be wrong.  ;-)

>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.

C line continuation is more than a bit of a mess*.  That problem has
always been possible with macros.

*Whitespace isn't significant except as a separator, unless it's
(not?) used to identify a line continuation?  Seriously?

>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.

So what additions to the standard library would you like?  There are a
number of useful items in there, but all of our usage is different.
Around here you'll see zero use of any of the scanf functions, for
example.

>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.

My (current) world does little FP, so again, I don't really care. OTOH
there certainly has been significant criticism of the IEEE float
support in C99.  OTTH, many of the people doing that complaining are
really complaining about IEEE float.

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

No opinion.

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

Thread

csiph-web