Errata

The table below lists all the known defects in the second printing of C: A Reference Manual (Fifth Edition), which was available in the Fall of 2002. Because some readers have the first printing, I have also included in this table the "severe" errors from the first printing, although they are fixed in the second printing. The minor and moderate errors in the first printing that were fixed in the 2nd printing are listed here. (No changes were made to the printed edition after the 2nd printing.)

The errata are sorted by page number. Severity is classified as "minor" for spelling, grammar, or formatting errors that cause no confusion; "moderate" for omissions, or errors that cause only minor confusion; and "severe" for instances where the text is wrong or too garbled to make sense of. The Reviewer column lists the people who first reported the problem; when there are two dated entries, the errata itself was later corrected. The Corrected column indicates in what printing the problem was fixed; if the entry is blank, then the correction is not yet scheduled for future printings.

What Printing Do I Have?

On the copyright page, just above the ISBN number, there is a sequence of integers, like this: 10  9  8  7  6  5  4  3  2  1.  The last number on the right is the number of the printing. In this example, it would be the first printing.

To Report a Problem

If you have the second printing of the book, please check that your problem is not already listed below, and then send me email at harbison@CAReferenceManual.com. If you have the first printing of the book, please also check the errata here before submitting a new problem.

Longer Corrections

Some problems listed in the table have corrections too long to put there. The corrections are listed below.

Page 253 (Order of Evaluation) [Corrected in 2nd Printing]

Section 7.12, Order of Evaluation, is incorrect in stating that Standard C implementations may assume that operators like + and * are fully commutative and associative. Those mathematical properties do not hold in limited-precision computer arithmetic. The value of an expression is defined abstractly by the Standard according to the associative rules of Table 7-3: The value of a+b+c+d is defined to be (((a+b)+c)+d), for example. A Standard C implementation can reorder an expression only if it can guarantee that the result of evaluating the reordered expression will be the same as the original expression for all possible values of the operands, including the effects of overflow or underflow. This effectively means that programmers can depend on their expressions being evaluated as written, without resorting to extraneous parentheses or the use of temporary variables. Traditional C did in fact permit reordering that could change the value of an expression, but that was changed in Standard C.

C99 allows floating-point expressions to be optimized (or contracted) to take advantage of fast computer instructions that combine multiple operators. Some of these instructions, such as multiply-add instruction found on some digital signal processors, might differ in their rounding or other behavior compared to the behavior of the C abstract machine. Contraction is controlled with pragma FP_CONTRACT; saying #pragma FP_CONTRACT OFF will disable contraction. The default setting of this pragma is implementation-defined.

Page 333 [Corrected in 2nd Printing]

The synopsis should be:

The example should be:

#include <iso646.h>
...
if (p || *p == 0)     *p ^= q;     /* customary */
if (p ??!??! *p == 0) *p ??'= q;   /* ISO C trigraphs */
if (p or *p == 0)     *p xor_eq q; /* ISO C iso646.h*/

Page 426 (math_errhandling, MATH_ERRNO, MATH_ERREXCEPT)

The following information should be added just before Section 17.1 on p. 426. Appropriate index entries should also be added.

C99 allows considerable flexibility in controlling which situations represent errors and which simply continue with infinite or NaN values. Two macros, MATH_ERRNO and MATH_ERREXCEPT are defined in C99 and have the values 1 and 2, respectively. The int expression math_errhandling may have the value of either of these macros, or the bitwise OR of both. If the expression math_errhandling & MATH_ERRNO is nonzero, then the implementation behaves in the traditional manner: Domain errors set errno to EDOM; range errors set errno to ERANGE; and it is implementation-defined if underflow sets errno to ERANGE. If the expression math_errhandling & MATH_ERREXCEPT is nonzero, then domain errors raise the FE_INVALID exception; range errors raise the FE_DIVBYZERO exception (if the result is exact infinity) or the FE_OVERFLOW exception (if the result is not exact infinity); and it is implementation-defined if underflow raises the FE_UNDERFLOW exception. Like errno, math_errhandling may be macro or variable. Its value will not change during the program's execution. An implementation must define the exceptions named above if it is ever possible for math_errhandling & MATH_ERREXCEPT to be nonzero.

References    EDOM, ERANGE, errno 11.2;  FE_DIVBYZERO, FE_INVALID, FE_OVERFLOW, FE_UNDERFLOW 22.3

Page 481 (FP_CONTRACT pragma) [Corrected in 2nd Printing]

The C99 standard pragma FP_CONTRACT was omitted from CARM5. The following text should be added as Section 22.5 on p. 481:

"22.5 Floating-Point Expression Contraction

Synopsis

#pragma STDC FP_CONTRACT on-off-switch

C99 allows floating-point expressions to be optimized (or contracted) to take advantage of fast computer instructions that combine multiple operators. Some of these instructions, such as the multiply-add instruction often found on digital signal processors, might differ in their rounding or other behavior compared to the requirements of the C abstract machine. Contraction is controlled with the standard pragma FP_CONTRACT: If on-off-switch has the value ON, contraction is permitted; if it has the value OFF, then contraction is forbidden. The default setting of this pragma is implementation-defined. The pragma follows the normal placement rules for standard pragmas (Section 3.7.2)."

Page 140, 197, 204, 211, ... (lvalues and arrays)

The book's treatment of "lvalue" is not completely consistent, mixing the traditional C and Standard C definitions. The gist of it is that an array name is a non-modifiable lvalue, and there are other expressions of type "array of T." Array names and array expressions, except when used as the operand of sizeof or the unary & operator or when a character array is initialized with a string constant, are immediately converted to pointers to the first element of the designated array and so behave as if they had pointer types. (See p. 197, "Conversion of Arrays and Functions.") Below are listed places in the text that need some adjustment:

• p. 140, Section 5.4.1: "when an array identifier appears in an expression" has to be qualified by the three exceptions to the rule.
• p. 204, in the first paragrah and Table 7-1: an array name is an lvalue (non-modifiable). Table 7-2: the operands to the increment, decrement, and compound assignment operators must be modifiable lvalues.
• p. 211, at the end of the first example: change "buffer is not an lvalue and cannot be modified." to "buffer is not a modifiable lvalue and so couldn't appear as the left operand of the assignment."
• p. 224, Section 7.5.6, in the paragraph before the second example: "In Standard C, the address operator applied to an lvalue of type “array of T”" should be "In Standard C, the address operator applied to an expression of type “array of T”."

This page was last updated 2006-08-22 14:24 -0400.