Ambiguous errata solutions for K&R2

I

Ioannis Vranos

In K&R2 errata page
<http://www-db-out.research.bell-labs.com/cm/cs/cbook/2ediffs.html>
there are some ambiguous errata, for which I propose solutions. Any
comments are welcome.



Ambiguous errata (mentioned first) of "The C Programming Language" 2nd
Edition errata page
(http://www-db-out.research.bell-labs.com/cm/cs/cbook/2ediffs.html), and
proposed solutions that should be added to the errata page exactly as
they appear:


1. "119-121(§5.11): The qsort discussion needs recasting in several ways.
First, qsort is a standard routine in ANSI/ISO C, so the rendition here
should be given a different name, especially because the arguments to
standard qsort are a bit different: the standard accepts a base pointer
and a count, while this example uses a base pointer and two offsets".


Proposed solution:

Rename the "qsort" references, declarations and definitions as "sort" in
the entire section 5.11.



2. "Also, the comparison-routine argument is not treated well. The call
shown on p 119, with an argument

(int (*)(void*,void*))(numeric? numcmp : strcmp)

is not only complicated, but only barely passes muster. Both numcmp and
strcmp take char * arguments, but this expression casts pointers to
these functions to a function pointer that takes void * arguments. The
standard does say that void * and char * have the same representation,
so the example will almost certainly work in practice, and is at least
defensible under the standard. There are too many lessons in these pages".


Proposed solution:

At the bottom of the page 119 (section 5.11), a note should be added:

"Note: In main(), the call with an argument (int
(*)(void*,void*))(numeric? numcmp : strcmp) is not only complicated, but
only barely passes muster. Both numcmp and strcmp take char * arguments,
but this expression casts pointers to these functions to a function
pointer that takes void * arguments. The standard does say that void *
and char * have the same representation, so the example will almost
certainly work in practice, and is at least defensible under the standard".



3. "195(§A4.1) The first few sentences might be reworded a bit to
emphasize that there is a distinction between storage duration and
scope, though both are influenced by explicit and implicit storage-class
specifiers".


Proposed solution:

Right after the sentence of A4.1, "Several keywords, together with the
context of an object's declaration, specify its storage class", the
following sentence should be added:

"There is a distinction between storage duration and scope, though both
are influenced by explicit and implicit storage-class specifiers".



4. "245(§B1.3, and also at p. 157 §7.4): The scanf functions do not
ignore white space in formats; if white space occurs at a place in the
format, any white space in the corresponding input is skipped".


Proposed solutions:

On page 157 (7.4) and on page 245 (B1.3), the first sentence with a *
(dot), should be replaced with the sentence:

"* If white space occurs at a place in the format, any white space in
the corresponding input is skipped".



5. "210(§A8.1): It is said that a register object cannot have the &
operator applied `explicitly or implicitly,' which is true, but needs an
amplifying clause to show that the implicit & comes from mention of an
array name, so declaring an array as a register is fruitless".


Proposed solution:

On page 210 (A8.1), after the sentence "However, if an object is
declared register, the unary & operator may not be applied to it,
explicitly or implicitly", the following sentence should be added:

"The implicit & comes from mention of an array name, so declaring an
array as a register is fruitless".



6. "There is no mention of the offsetof macro in B".

"Index: stddef.h is listed but not summarized in the text; It needs a
section in Appendix B".


Proposed solutions:

At the end of Appendix B, (page 258) the following should be added:

"B12. Common standard type definitions: <stddef.h>

The header <stddef.h> defines the following types and macros:

The types are:

ptrdiff_t
A signed integral type of the result of subtracting two pointers.

wchar_t
An integral type whose range of values can represent distinct
wide-character codes for all members of the largest extended character
set specified among the supported locales; the null character has the
code value 0 and each member of the basic character set has a code value
equal to its value when used as the lone character in an integer
character constant.

size_t
An unsigned integral type of the result of the sizeof operator.


The macros are:

NULL
NULL expands to an implementation-defined null pointer constant.

offsetof(type, member-designator)
offsetof expands to an integral constant expression of type size_t,
the value of which is the offset in bytes to the structure member
(member-designator), from the beginning of its structure (type)".


Also a reference to offsetof should be added in the INDEX section (page
268).
 
P

Peter Nilsson

Ioannis said:
In K&R2 errata page
<http://www-db-out.research.bell-labs.com/cm/cs/cbook/2ediffs.html>
there are some ambiguous errata, for which I propose solutions. Any
comments are welcome.

The fact that your 'solutions' are in keeping with the errata suggests
that the mentioned errata are not ambiguous.

In many cases, the errata are simply statements that the text is
incorrect or flawed. Few of the errata state what the rewrite should
be, which is what your 'solutions' seem to do (without explaining
the error in most cases.)

Since there is no plan release K&R3 AFAIK, it seems a little pointless
to suggest rewrites of the actual text.
 
I

Ioannis Vranos

Peter said:
The fact that your 'solutions' are in keeping with the errata suggests
that the mentioned errata are not ambiguous.


They are ambiguous in the sense that they do not prompt the book owner
to perform a specific solution, like the other ones.

In many cases, the errata are simply statements that the text is
incorrect or flawed. Few of the errata state what the rewrite should
be, which is what your 'solutions' seem to do (without explaining
the error in most cases.)

Since there is no plan release K&R3 AFAIK, it seems a little pointless
to suggest rewrites of the actual text.


Well, if something is wrong or missing, why not fix it, as the rest of
the errata of this book?
 
P

Peter Nilsson

Ioannis said:
Well, if something is wrong or missing, why not fix it,

Presumably because the author's lives have moved on since this book
was last published 20 years ago. I see no compelling reason to drag
them back to the writing desk if they don't wish to do so.
as the rest of the errata of this book?

Ask DMR to update his errata. But replacement pages for the
original text is not my idea of an errata.
 
I

Ioannis Vranos

Peter said:
Presumably because the author's lives have moved on since this book
was last published 20 years ago. I see no compelling reason to drag
them back to the writing desk if they don't wish to do so.

I didn't drag them back without their wish.
Ask DMR to update his errata. But replacement pages for the
original text is not my idea of an errata.


Well, the rest of errata were of the style:

On page xyz, section abc, replace this with this. For the "ambiguous
errata" I am talking about, there is not a suggested action for fixing
the errors/ommissions. I tried to do this based strictly on their errata
comments.


And I wrote section B12 myself, based on C89 draft and an on-line page.
Have you checked it?
 
U

user923005

Presumably because the author's lives have moved on since this book
was last published 20 years ago. I see no compelling reason to drag
them back to the writing desk if they don't wish to do so.

It's still a top seller. I guess that they would be intersted in
suggestions for improvements
 
I

Ioannis Vranos

I sent via email the following to DMR and BWK:


Dear Mr. Brian Kernighan and Mr. Dennis Ritchie,

At the errata page of "The C Programming Language" 2nd Edition
(<http://www-db-out.research.bell-labs.com/cm/cs/cbook/2ediffs.html>),
most of the errata are of the style "On page xyz, section abc, replace
this with this" or "On page xyz, section abc, add this to this".


However there are some errata that I call "ambiguous", about which there
is not a suggested specific action for fixing the errors/omissions.

So I am sending to you some proposed solutions for these, that I made,
based strictly on their errata comments.


These proposed solutions are to be added to the errata page exactly as
they appear after the phrase "Proposed solution:", replacing their
"ambiguous" corresponding text.




1. "119-121(§5.11): The qsort discussion needs recasting in several
ways. First, qsort is a standard routine in ANSI/ISO C, so the rendition
here should be given a different name, especially because the arguments
to standard qsort are a bit different: the standard accepts a base
pointer and a count, while this example uses a base pointer and two
offsets".


Proposed solution:

Rename the "qsort" references, declarations, definitions and calls, as
"sort" in the entire section 5.11.



2. "Also, the comparison-routine argument is not treated well. The call
shown on p 119, with an argument

(int (*)(void*,void*))(numeric? numcmp : strcmp)

is not only complicated, but only barely passes muster. Both numcmp and
strcmp take char * arguments, but this expression casts pointers to
these functions to a function pointer that takes void * arguments. The
standard does say that void * and char * have the same representation,
so the example will almost certainly work in practice, and is at least
defensible under the standard. There are too many lessons in these pages".


Proposed solution:

At the bottom of the page 119 (section 5.11), a note should be added:

"Note: In main(), the call with an argument (int
(*)(void*,void*))(numeric? numcmp : strcmp) is not only complicated, but
only barely passes muster. Both numcmp and strcmp take char * arguments,
but this expression casts pointers to these functions to a function
pointer that takes void * arguments. The standard does say that void *
and char * have the same representation, so the example will almost
certainly work in practice, and is at least defensible under the standard".



3. "195(§A4.1) The first few sentences might be reworded a bit to
emphasize that there is a distinction between storage duration and
scope, though both are influenced by explicit and implicit storage-class
specifiers".


Proposed solution:

Right after the sentence of A4.1, "Several keywords, together with the
context of an object's declaration, specify its storage class", the
following sentence should be added:

"There is a distinction between storage duration and scope, though both
are influenced by explicit and implicit storage-class specifiers".



4. "245(§B1.3, and also at p. 157 §7.4): The scanf functions do not
ignore white space in formats; if white space occurs at a place in the
format, any white space in the corresponding input is skipped".


Proposed solution:

On page 157 (7.4) and on page 245 (B1.3), the first sentence with a *
(dot), should be replaced with the sentence:

"* If white space occurs at a place in the format, any white space in
the corresponding input is skipped".



5. "210(§A8.1): It is said that a register object cannot have the &
operator applied `explicitly or implicitly,' which is true, but needs an
amplifying clause to show that the implicit & comes from mention of an
array name, so declaring an array as a register is fruitless".


Proposed solution:

On page 210 (A8.1), after the sentence "However, if an object is
declared register, the unary & operator may not be applied to it,
explicitly or implicitly", the following sentence should be added:

"The implicit & comes from mention of an array name, so declaring an
array as a register is fruitless".



6. "There is no mention of the offsetof macro in B".

"Index: stddef.h is listed but not summarized in the text; It needs a
section in Appendix B".


Proposed solution:

At the end of Appendix B (page 258), the following should be added:

"B12. Common standard type definitions: <stddef.h>

The header <stddef.h> defines the following types and macros:

The types are:

ptrdiff_t
A signed integral type of the result of subtracting two pointers.

wchar_t
An integral type whose range of values can represent distinct
wide-character codes for all members of the largest extended character
set specified among the supported locales; the null character has the
code value 0 and each member of the basic character set has a code value
equal to its value when used as the lone character in an integer
character constant.

size_t
An unsigned integral type of the result of the sizeof operator.


The macros are:

NULL
NULL expands to an implementation-defined null pointer constant.

offsetof(type, member-designator)
offsetof expands to an integral constant expression of type size_t,
the value of which is the offset in bytes to the structure member
(member-designator), from the beginning of its structure (type)".


Also a reference to offsetof should be added in the INDEX section (page
268), and the page number 258 should be added to the reference of
<stddef.h> header, in the INDEX section (page 270).
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top