Groups > comp.lang.c > #53628 > unrolled thread

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

Started by	Kamel Biskri <email@domain.com>
First post	2014-11-28 23:45 +0100
Last post	2015-02-06 09:12 -0500
Articles	9 on this page of 129 — 23 participants

Back to article view | Back to comp.lang.c

Page 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]

#57011

From	James Kuyper <jameskuyper@verizon.net>
Date	2015-02-05 14:18 -0500
Message-ID	<54D3C212.6000602@verizon.net>
In reply to	#57009

On 02/05/2015 02:04 PM, Robert Wessel wrote:
> 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:
...
> 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.

[u]int64_t, [u]int_least64_t, [u]int_fast64_t and [u]intmax_t all have
at least 64 bits, were all introduced in the same version of the C
standard, and were all needed for consistency with the other size-named
types. "long long" was needed only for compatibility with existing
non-standard code, not because a 64-bit type was needed.

I argued against making [u]int_least64_t and [u]int_fast64_t mandatory -
the only reason any implementation would fail to provide them would be
if the implementor knew that implementing those types would be so
inefficient on that platform that no customer would want to use them. We
should trust implementors to know their customers (or go out of
business). That argument was not accepted - but then, I only presented
it in usenet newsgroups, not directly to the committee.

[toc] | [prev] | [next] | [standalone]

#57037

From	Robert Wessel <robertwessel2@yahoo.com>
Date	2015-02-05 18:35 -0600
Message-ID	<3418dahvgdrjsd652u6u692jqlnhb725t8@4ax.com>
In reply to	#57011

On Thu, 05 Feb 2015 14:18:42 -0500, James Kuyper
<jameskuyper@verizon.net> wrote:

>On 02/05/2015 02:04 PM, Robert Wessel wrote:
>> 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:
>...
>> 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.
>
>[u]int64_t, [u]int_least64_t, [u]int_fast64_t and [u]intmax_t all have
>at least 64 bits, were all introduced in the same version of the C
>standard, and were all needed for consistency with the other size-named
>types. "long long" was needed only for compatibility with existing
>non-standard code, not because a 64-bit type was needed.
>
>I argued against making [u]int_least64_t and [u]int_fast64_t mandatory -
>the only reason any implementation would fail to provide them would be
>if the implementor knew that implementing those types would be so
>inefficient on that platform that no customer would want to use them. We
>should trust implementors to know their customers (or go out of
>business). That argument was not accepted - but then, I only presented
>it in usenet newsgroups, not directly to the committee.

Well, having the main name of the (at least) 64 bit type by
(u)int_least64_t would have been even uglier than long long, but I'd
have been satisfied.  Although I think a name *that* ugly might have
convinced me that a typedef of macro to produce a more sensible name
would have actually been justified.

That being said, I have trouble understanding some of the optional
stuff in the C standard.  Take complex, for instance.  Now I've never
used C99 complex, mainly because all of the times I've needed that
I've either rolled-my-own (much of that predating the availability of
C99, and some of that is still floating around our code) with the
usual ugly function-call based operators, or the requirement was
enough to justify C++, at least in "enhanced C" mode.

Yet the complex functions are somewhat bizarrely optional for
freestanding implementations, despite having little actual overhead to
support in the compiler, and basically no overhead to support at
runtime if they're not used.  And even if they're used, the basic
(non-library) functions are pretty trivial to implement, either as
inline real FP or CRT calls.  A bit worse if you were actually trying
to get IEEE math compliance (but that's often a non-issue on
freestanding platforms).  Any overhead, such as the ballooning of the
printf/scanf functions, can obviously be handled the same way that
compilers for small targets now handle FP (usually a compiler or
linker option to eliminate FP support).

OTOH, some stuff like VLAs, are certainly are going to have issues on
certain small targets, yet were not optional for freestanding hosts in
C99.

And I'm just not sure what platform would be limited enough that it
supported an approximate full implementation of freestanding C, but
could not manage a 64 bit type.  Heck, if you had (as you must) a 32
bit type, you could hack up all of the necessary 64 bit functions (the
four basic functions, negation, a few comparisons, some logical
functions, extension and truncation) in no more than a couple of
hundred lines of C, and the performance of the individual operations
would be no more than several times worse than the equivalent 32 bit
operations (perhaps division excepted).  You could probably do a fair
bit better in assembler on most platforms.  And again, these might
well be zero overhead if you never used a 64 bit type.

Which is not to say I don't see all sorts of cases for optional
features.  For example, a standard networking interface could well be
optional.

[toc] | [prev] | [next] | [standalone]

#57054

From	James Kuyper <jameskuyper@verizon.net>
Date	2015-02-06 08:47 -0500
Message-ID	<mb2gju$9h4$1@dont-email.me>
In reply to	#57037

On 02/05/2015 07:35 PM, Robert Wessel wrote:
> On Thu, 05 Feb 2015 14:18:42 -0500, James Kuyper
> <jameskuyper@verizon.net> wrote:
...
>> I argued against making [u]int_least64_t and [u]int_fast64_t mandatory -
>> the only reason any implementation would fail to provide them would be
>> if the implementor knew that implementing those types would be so
>> inefficient on that platform that no customer would want to use them. We
>> should trust implementors to know their customers (or go out of
>> business). That argument was not accepted - but then, I only presented
>> it in usenet newsgroups, not directly to the committee.
...
> And I'm just not sure what platform would be limited enough that it
> supported an approximate full implementation of freestanding C, but
> could not manage a 64 bit type.  Heck, if you had (as you must) a 32
> bit type, you could hack up all of the necessary 64 bit functions (the
> four basic functions, negation, a few comparisons, some logical
> functions, extension and truncation) in no more than a couple of
> hundred lines of C, and the performance of the individual operations
> would be no more than several times worse than the equivalent 32 bit
> operations (perhaps division excepted). 

What if implementation of 32-bit operations were already a strain, such
as on a system where the only integer type with hardware support has
only 8 bits? I'm not saying it's impossible for such a system to
implement a 64-bit type; merely that the customers for that platform are
unlikely to need one, given how costly use of that type would be. I
think an implementation shouldn't have to be considered non-conforming
just because it fails to provide such a type.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#57103

From	Robert Wessel <robertwessel2@yahoo.com>
Date	2015-02-07 00:32 -0600
Message-ID	<3rbbdatn1btmddt3rn23maa3sh6hgq1i9d@4ax.com>
In reply to	#57054

On Fri, 06 Feb 2015 08:47:13 -0500, James Kuyper
<jameskuyper@verizon.net> wrote:

>On 02/05/2015 07:35 PM, Robert Wessel wrote:
>> On Thu, 05 Feb 2015 14:18:42 -0500, James Kuyper
>> <jameskuyper@verizon.net> wrote:
>...
>>> I argued against making [u]int_least64_t and [u]int_fast64_t mandatory -
>>> the only reason any implementation would fail to provide them would be
>>> if the implementor knew that implementing those types would be so
>>> inefficient on that platform that no customer would want to use them. We
>>> should trust implementors to know their customers (or go out of
>>> business). That argument was not accepted - but then, I only presented
>>> it in usenet newsgroups, not directly to the committee.
>...
>> And I'm just not sure what platform would be limited enough that it
>> supported an approximate full implementation of freestanding C, but
>> could not manage a 64 bit type.  Heck, if you had (as you must) a 32
>> bit type, you could hack up all of the necessary 64 bit functions (the
>> four basic functions, negation, a few comparisons, some logical
>> functions, extension and truncation) in no more than a couple of
>> hundred lines of C, and the performance of the individual operations
>> would be no more than several times worse than the equivalent 32 bit
>> operations (perhaps division excepted). 
>
>What if implementation of 32-bit operations were already a strain, such
>as on a system where the only integer type with hardware support has
>only 8 bits? I'm not saying it's impossible for such a system to
>implement a 64-bit type; merely that the customers for that platform are
>unlikely to need one, given how costly use of that type would be. I
>think an implementation shouldn't have to be considered non-conforming
>just because it fails to provide such a type.


I'd say you could leave that to the implementers to deal with, in the
same way they deal with float on such small platforms, assuming there
was any meaningful runtime burden (IOW, if you never multiply two 64
bit numbers, _crt_mult_i64() is never going to be called, so it should
not be hauled in by the linker*, perhaps the support in *printf()
would need a compiler/linker switch).

I think you're overestimating the complexity of 64 bit support - it's
pretty trivial, even on 8-bit boxes.


*And if the implementer can't write the runtime and/or linker
competently enough to do that, just too bad.  And yes, I know that
many of the C implementations for microcontrollers have been horrid.

[toc] | [prev] | [next] | [standalone]

#57021

From	Richard Heathfield <rjh@cpax.org.uk>
Date	2015-02-05 21:53 +0000
Message-ID	<mb0oo8$h3u$1@dont-email.me>
In reply to	#57009

On 05/02/15 19:04, Robert Wessel wrote:

<snip stuff we either agree on, or never will>

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

Um, you've kind of caught me out with that question. I'm sure I could 
think of plenty, given time... but right now, I'm more or less happy 
with what we've got.

Oh! Yeah, a function called something like strsplit(), that would take a 
string and chop it up into tokens. You'd give it, er, the const char *, 
and a char *** or something like that (I haven't spent much time 
thinking about this!), and a size_t *, oh yeah, and a char 
*separatorlist, and it would create and populate an array of strings for 
you. A sort of instant strtok loop (but without any statics).

> Around here you'll see zero use of any of the scanf functions, for
> example.

<topper>
I think I can beat that. I think my usage of *scanf is very slightly 
negative. :-)
</topper>

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

[toc] | [prev] | [next] | [standalone]

#57005

From	James Kuyper <jameskuyper@verizon.net>
Date	2015-02-05 12:17 -0500
Message-ID	<54D3A5B9.2070709@verizon.net>
In reply to	#56982

On 02/05/2015 08:18 AM, David Brown wrote:
...
> You are going to have to justify that last statement.  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" ?

I think that the fundamental problem with C99 was not that it was a
mess, but simply because it wasn't strongly motivated. I wrote C code
before the language was standardization - coping with portability issues
was a nightmare. The standard allows a wide range of variation between
different implementations, but it also specifies what can and cannot
vary, which greatly simplifies the writing of portable code. That alone
was enough to ensure that C90 was adopted very quickly. The advantages
of C99, though quite real, were too minor to motivate rapid adoption.
With implementors not adopting it rapidly, users had little motive to
adopt it, and vice versa.

[toc] | [prev] | [next] | [standalone]

#57047

From	David Brown <david.brown@hesbynett.no>
Date	2015-02-06 10:26 +0100
Message-ID	<mb21bb$g99$1@dont-email.me>
In reply to	#57005

On 05/02/15 18:17, James Kuyper wrote:
> On 02/05/2015 08:18 AM, David Brown wrote:
> ...
>> You are going to have to justify that last statement.  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" ?
> 
> I think that the fundamental problem with C99 was not that it was a
> mess, but simply because it wasn't strongly motivated. I wrote C code
> before the language was standardization - coping with portability issues
> was a nightmare. The standard allows a wide range of variation between
> different implementations, but it also specifies what can and cannot
> vary, which greatly simplifies the writing of portable code. That alone
> was enough to ensure that C90 was adopted very quickly. The advantages
> of C99, though quite real, were too minor to motivate rapid adoption.
> With implementors not adopting it rapidly, users had little motive to
> adopt it, and vice versa.
> 

I can agree on that point.  It took a long time before C99 was adopted
by compiler vendors - and even longer before they supported all the
little details (if they even do so now).  C11 looks to be in a similar
situation - the /real/ changes are even smaller (and potentially useful
ones, like atomics, are a decade or two too late), and it will take a
good while before it becomes at all relevant for code.

Compare that to C++11, where the language changes were very significant
and have been quickly adopted by compilers and programmers alike.  It is
a bit more akin to the C change from K&R to C89/ANSI.

[toc] | [prev] | [next] | [standalone]

#56985

From	"Osmium" <r124c4u102@comcast.net>
Date	2015-02-05 08:26 -0600
Message-ID	<cjhct8FlfsrU1@mid.individual.net>
In reply to	#53628

"Kamel Biskri"

> I did search a bit for an answer without finding one.
> Why did K&R did not update thier book past C89?
> Is there any official answer to that question? It's like the Stevens book, 
> but in the end the later has been updated even if it's by another author.

I am of an age similar to the authors.  I find that as I get older, energy 
declines and I am less and less interested in time consuming projects.  I 
know enough to know what an insane amount of time can be spent making 
something of a quality suitable for publication. I once spent three weeks, 
more or less, producing a 7,000 word journal article. The drawings are a 
royal PITA since someone else does them. You can't even talk to him, he 
lives somewhere else. I have had about 10 articles printed over the years - 
some in CACM -, I just happen to have numbers of a sort for that one 
article. And that sample was with the assistance of an superb editor, from 
the little reading I do now, it seems the editors have been replaced by 
spell checkers. THAT does not work.

I never cease to be amazed at the number of people who are willing to go to 
a lot of effort to make money.  For myself, I have enough, The only thing I 
have is time. Why trade time for even more money?

Another factor, K&R is such an incredible achievement, a successor couldn't 
possibly be better and there is some probability that it might be worse. 
Why chance messing up a great legacy for money you don't need?

As far as another author doing the update, it is *conceivable* that Prentice 
Hall has some standards, It is certainly a deceptive practice to retain the 
title, especially for such a great book, with a different author.

[toc] | [prev] | [next] | [standalone]

#57057

From	James Kuyper <jameskuyper@verizon.net>
Date	2015-02-06 09:12 -0500
Message-ID	<mb2i3k$fug$1@dont-email.me>
In reply to	#56985

On 02/05/2015 09:26 AM, Osmium wrote:
...
> I never cease to be amazed at the number of people who are willing to go to 
> a lot of effort to make money.  For myself, I have enough, The only thing I 
> have is time. Why trade time for even more money?

ITYM "The only thing I have in short supply is time."
-- 
James Kuyper

[toc] | [prev] | [standalone]

Page 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]

csiph-web

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

Contents

#57011

#57037

#57054

#57103

#57021

#57005

#57047

#56985

#57057