Although not about C++ only, I think many people here have K&R2, so I
post this message in clc++ too.
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.../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.hdefines 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).
