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

From	Keith Thompson <kst-u@mib.org>
Newsgroups	comp.lang.c
Subject	Re: Why the C programming language book was never updated past C89?
Date	2015-02-05 10:47 -0800
Organization	None to speak of
Message-ID	<lnoap8kxf2.fsf@nuthaus.mib.org> (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>
Show all headers | View raw
Richard Heathfield <rjh@cpax.org.uk> writes:
> 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
[...]
(nothing to add)

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

I disagree.  Mixing declarations and statements (the word "code" seems
ambiguous) makes it easier to move declarations closer to where they're
used, and to initialize objects with their declarations:

    {
        int x = ...;
        /* do some computations that modify x */
        const int y = x * 2;
        /* code that uses y */
    }

In C90, I could do the same thing by introducing a new scope:

    {
        int x = ...;
        /* do some computations that modify x */
        {
            const int y = x * 2;
            /* code that uses y */
        }
    }

The alternative is:

    {
        int x = ...;
        int y;
        /* do some computations that modify x */
        y = x * 2;
        /* code that uses y */
    }

but then it's difficult to tell at a glance that the assignment is the
only thing that sets the value of y.

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

Backward compatibility often prevents changing the sizes of fundamental
types, or at least makes it difficult.

I know you find the name "long long int" ugly, which is understandable,
but I don't share your dislike.

I do think we need to be able to have a number of distinct integer
types, and it's not clear just how many.  Making long int 64 bits means
imposes restrictions on the smaller types; we'd pretty much have to have
8-bit char, 16-bit short, and 32-bit int if we want to cover all the
obvious sizes.  (This is for typical implementations; exotic things like
37-bit one's-complement integers are another matter.)

Very old (pre-K&R) C didn't have the short, long, or unsigned keywords.
It soon became obvious that just having a single integer type `int`
wasn't sufficient.  The problem is that additional integer types were
added to the language in an ad-hoc manner.

I'd like to see a mechanism that permits an implementation to provide an
arbitrary collection of integer types in a coherent manner.
Unfortunately, it's too late to change C, though <stdint.h> does provide
a reasonably coherent layer o top of the "type safari park".

I do think that adding long long was a goodd idea.

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

As others have mentioned, that point of failure (insufficient memory to
allocate a VLA object) applies to fixed-size arrays as well.  VLAs do
make it easier to run into it.

I've previously pointed out that you can use VLA types without having
local VLA objects.  You can define a type:

    size_t height = /* ... */;
    size_t width  = /* ... */;
    typedef vla[height][width];
    vla *p = malloc(sizeof *p);

You can check whether the allocation succeeded or failed, and you can
then use ordinary indexing operations on *p, and they'll automatically
adjust for the non-constant array dimentions.

On the other hand, such a type can only be defined inside a function,
which seriously limits its usefulness.

One thing I find annoying about C11 is that VLAs were made *optional*.
As a programmer, I can choose whether or not to use VLAs.  Why should
the implementer of my compiler make that choice for me?  Were there
vendors who refused to implement C11 unless they could omit VLAs?

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

Nothing to add.

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

If I were designing a new language from scratch, it would probably
*only* have end-of-line comments.  Multi-line comments can trivially be
built from them, and comments in the middle of a line are rarely useful.
If it did support comments in the middle of a line, they wouldn't be
permitted to occupy more than one line.

I'm sure a lot of people would hate such a language.  Don't worry,
there's little risk that I'll ever get around to designing or
implementing it.

The trailing backslash problem is potentially serious.  It can be partly
addressed by having compilers warn about line continuations within
end-of-line comments (which very likely to be mistakes).  One other
thing I'd change is to make a trailing backslash *followed by
whitespace* act aa a line continuation.  An invisibly modified version
of your example:

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

would call bar (given a conforming compiler), because I added a space
after the final \.  But I think some preprocessors get this wrong (or
perhaps they justify it via some kind of transformation in translation
phase 1).

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

snprintf() is very nice; it lets you *safely* build formatted strings.

C99 also added float and long double versions of the mathematical
functions.

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

Personally, I really like <stdint.h> and <stdbool.h>.  (I'm not crazy
about the way bool was added to the language, but I think adding it was
a good idea, and the ugliness was probably necessary for backward
compatibility.)

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

Likewise.

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

In many cases I find code that uses them much more readable.

    struct foo obj = { 2, true, "", 7 };

What does `true` mean in this context?  Why should I have to care about
the order in which the members were defined?

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

As usual, I respect your opinions; I just don't share all of them.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
Thread

csiph-web