Errata (1st Printing)

This table lists those errata in the first printing which were subsequently fixed in the second printing.  The corrections have been sent to the publisher, and I expect the second printing in the Fall of 2002. The errata that remain after the first printing are listed here. That page also explains how to determine what printing you have and how to submit more errata.

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

Severity Location Description Date posted & Reviewer Corrected
minor Ch. 1, p. 4 On the line 8 of Section 1.1.2, "under by P. J. Plauger" should be "under P. J. Plauger". 3/30/02
Beebe		 2nd
printing
minor Ch. 2, p. 17 Fourth paragraph, beginning “The sequence...”: Vertical bars should be replaced with up-arrows. That is, ab|?x should be ab↑?x, and a|b should be a↑b. 3/26/02
Molenda,
Atkinson		 2nd
printing
minor Ch. 2, p. 41 On line 13, "whose short identifier are" should be "whose short identifier is". 3/30/02
Beebe		 2nd
printing
minor Ch. 3, p. 51 Third line from end of Sec. 3.3.3: #define cha unsigned char should be #define char unsigned char  (spacing problem) 7/22/02
Dasdan		 2nd
printing
minor Ch. 3, p. 65 Fourth line from the bottom: uintmax_T should be uintmax_t. 5/27/02
Pöschl		 2nd
printing
severe Ch. 3, p. 67, 68 The last sentence of the paragraph following the #pragma syntax in Section 3.7 should be changed to: "Except in the case of a C99 standard pragma (Section 3.7.1), whether the tokens following #pragma are subject to macro expansion is implementation-defined. If a nonstandard pragma is macro expanded and the expansion has the form of a standard pragma, then it is implementation-defined whether the pragma is in fact treated like a standard pragma."

On p. 68, the second sentence of Section 3.7.1 should be changed to: "To differentiate them, all standard pragmas must be preceded by the token STDC (before any implementation-defined macro expansion), and the following tokens must not be macro expanded." [A minor wording change was also made in the last sentence of this section to compensate for the length of the former addition.]

 5/27/02
Pöschl		 2nd
printing
moderate Ch. 3, p. 68 In the References section at the end of Section 3.7.1, add: "FP_CONTRACT  22.5" (and see below) 7/22/02
Spector		 2nd
printing
minor Ch. 4, p. 76 First code line of the example: the ";" is hidden by the "/" which overstrikes it. 4/4/02
Beebe		 2nd
printing
minor Ch. 4, p. 91 Third line from the end of the example beginning on that page: p = (int *)pc; /* Valid, but dangerous */ There is an incorrect space in "pc", making it appear "p c". 7/22/02
Dasdan		 2nd
printing
minor Ch. 4, p. 101 Sixth line after Table 4-5: "wit'h" should be "with". 4/04/02
Beebe		 2nd
printing
severe Ch. 4, p. 104 Table 4-6, Form of Initializers, is partially incorrect. The qualifiers, "(or nonconstant expressions in C99)," belong on the "automatic" storage table rows, not on the "static" storage rows. Static storage objects can only be initialized with constant expressions, even in C99. Automatic storage objects may be initialized by nonconstant expressions in C99, but previous versions of C required constant expressions. 5/27/02
Hedquist		 2nd
printing
minor Ch. 4, p. 117 Two lines above Section 4.9.4: The "*/" overstrikes the preceding comment text.  4.04/02
Beebe		 2nd
printing
minor Ch. 5, p. 133 In the last paragraph, second line, "though" should be "through." 5/27/02
Pöschl		 2nd
printing
moderate Ch. 5, p. 141 The last sentence should be changed to: "That is, those elements that only differ by one in their last subscript are stored adjacently." 5/27/02
Beebe		 2nd
printing
minor Ch. 5, p. 142 In the last line on the page, "parameterlike this:" should be "parameter, like this:". 7/22/02
Dasdan		 2nd
printing
minor Ch.5, p. 149 Under the drawing of the struct complex data object, "struct com-" should be "struct complex". 7/22/02
Dasdan		 2nd
printing
minor Ch. 5, p. 154 In the second line after the first figure, the phrase "to which p points" is missing a space after "which." 
Also, in the last line of the first Example, there should not be a space in the expression "&s.z".		 5/27/02
Beebe		 2nd
printing
minor Ch. 5, p. 160 In the seventh line, there is a spacing problem in "pointer to S". 5/27/02
Beebe		 2nd
printing
moderate Ch. 5, p. 165 In the first step of the Example, the top box should contain the text "float (4 bytes)". 5/27/02
Beebe		 2nd
printing
minor Ch. 5, p. 169 In the second code block of the first Example, there are some spacing problems: the /* characters should line up vertically. 5/27/02
Beebe		 2nd
printing
minor Ch. 6, p. 188 Four lines from the end of Section 6.1.6, the phrase "with memcopy" has a spacing problem. 5/27/02
Beebe		 2nd
printing
minor Ch. 6, p. 196 In the last line before the example near the bottom of the page, the phrase "see Section 6.2.7 for" has a spacing problem. 5/27/02
Beebe		 2nd
printing
moderate Ch. 7, p. 205 In the seventh line of Table 7-3, "(type name}{init}" should be "(type name) {init}". 5/27/02
Pöschl		 2nd
printing
minor Ch. 7, p. 235 In the last line on the page, the phrase "the unary ! operator" has a spacing problem. 5/27/02
Beebe		 2nd
printing
severe Ch. 7, p. 240 In the extern declaration of next_set_of_n_elements in set.h, "PARMS((SET x))" should be simply "(SET x)".  Without this change, the example files will not compile. I have corrected the example files on this site, also.  (4/4/02: added missing newline at end of file.) 3/31/02
Beebe		 2nd
printing
minor Ch. 7, p. 249 The third line following Table 7-8 is correct, but it might be clearer to write, "x=-1 could be interpreted as either x=(-1) or x=x-1." A similar change can be made in the fifth line. 5/27/02
Beebe		 2nd
printing
severe Ch. 7, p. 253, 254 Section 7.12, Order of Evaluation, is incorrect. Standard C implementations cannot reorder expressions as arbitrarily as this section states. See the discussion below. 5/27/02
Beebe		 2nd
printing
minor Ch. 7, p. 256 In the second group of examples, the semicolon in  "x + ( a *= 2);" is obscured. 5/27/02
Pöschl		 2nd
printing
minor Ch. 9, p. 298 In the sixth line from the bottom, "anint" should be "an int". 7/22/02
Beebe		 2nd
printing
moderate Ch. 9, p. 303 In the paragraph following the code examples of main, the final sentence ends "...may be used to obtain it." This should be changed to "... may be used to obtain other information from the environment."  Information can be passed to a program using getenv and system, but command-line arguments cannot be obtained by those functions. 7/22/02
Beebe		 2nd
printing
moderate Ch. 9, p. 307 Section 9.11.4, add the following sentence at the end of the paragraph: 'In C++, if control reaches the end of main, then it is as if an implicit "return 0;" were executed.'  (Prior to C99, the return value would be undefined. In C99 and in all C++ functions except main, this would be illegal.) 7/22/02
Beebe		 2nd
printing
moderate Ch. 10, p. 313

Section 10.1.1 (Reserved Library Identifiers). A specific list of identifiers reserved in C is given below.

 7/22/02
Beebe		 2nd
printing
severe Ch. 11, p. 333 The synopsis and example on this page are garbled. See the replacement text below. 3/26/02
Atkinson		 2nd
printing
minor Ch. 15, p. 366 [Clarification] Standard C specifies that FOPEN_MAX must be at least 8, and its value is often much larger. However, the target operating system may limit the number of open files depending on resources currently available, and may publish that limit through other means. 7/22/02
Beebe		 2nd
printing
moderate Ch. 15, p. 367 In line 9 of the code example: if (filename == NULL) filename = "\0";  should be  if (filename == NULL) filename = "";  7/22/02
Beebe		 2nd
printing
minor Ch. 15, p. 375 Eleven lines from the bottom: "streamwithout" should be "stream without". 7/22/02
Beebe		 2nd
printing
minor Ch. 15, p. 397 In the last line of the section "The p conversion": "unommon" should be "uncommon". 7/22/02
Beebe		 2nd
printing
moderate Ch. 15, p. 405 [Clarification] The use of tmpnam, tmpfile, and mktemp have been identified as security problems on many systems, because the files may be accessible to other users while they are being used. You may wish to find more secure versions of these functions, such as mkstemp (FreeBSD). [A new paragraph was added at the end of the page explaining this.] 7/22/02
Beebe		 2nd
printing
minor Ch. 16, p. 408 Beginning eight lines before the last example: "returns either null pointer" should be "returns either a null pointer". 7/22/02
Beebe		 2nd
printing
minor Ch. 16, p. 410 In the first synopsis section, there are superfluous spaces in some function names, including malloc, calloc, and realloc. 5/27/02
Pöschl		 2nd
printing
minor Ch 16, p. 412 Starting on the first line of the second paragraph: "ptr (if not null) designates a char * pointer" should be "ptr (if not null) designates a char ** pointer". 7/22/02
Beebe		 2nd
printing
minor Ch. 16, p. 413 The subheading "Integer conversions" has some incorrect spacing. 5/27/02
Pöschl		 2nd
printing
moderate Ch. 16, p. 416 In the third line on the page, "setenv" should be "setenv or putenv". 7/22/02
Beebe		 2nd
printing
minor Ch. 16, p. 419 In the eighth line from the bottom, add a forward reference: "..provided by imaxabs in inttypes.h (Section 21.7)." 7/22/02
Beebe		 2nd
printing
moderate Ch. 17, p. 425 On the eighth line from the bottom of the page, the file tgtdef.h should be tgmath.h. 3/30/02
Carlini		 2nd
printing
minor Ch. 17, p. 427 In the heading of Section 17.3, there are extra spaces before trunc. 7/22/02
Beebe		 2nd
printing
minor Ch. 17, p. 430 In the third line, "partf" should be "part f". 7/22/02
Beebe		 2nd
printing
moderate Ch. 17, p. 432 In the second paragraph: Change the last sentence to read: "C99 requires that hypot compute its result without undue overflow or underflow, such as would result by writing sqrt(x*x+y*y)." 7/22/02
Beebe		 2nd
printing
moderate Ch. 17, p. 435 On the third line: asin should be asinh; 4th line: atan should be atanh. 3/26/02
Howe		 2nd
printing
minor Ch. 17, p. 439 In the first line of the synopsis, change "All new in C99" to "All new in C99 but common in UNIX" 7/22/02
Beebe		 2nd
printing
moderate Ch. 19, p. 455, 456 In the second line following the in-text example on p. 455: Change the entire sentence beginning, "Standard C requires that longjmp operate correctly..." to "C89  required that longjmp operate correctly in unnested signal (interrupt) handlers, but C99 dropped that requirement. Interrupt handlers should be considered implementation-defined."

Similarly, on p. 456, the second line from the bottom: change "exit or longjmp" to "exit".

 7/22/02
Beebe		 2nd
printing
moderate Ch. 19, p. 457 In the example in the middle of the page, change both occurrences of 'printf("?Couldn't...' to be 'fprintf(stderr,"?Couldn't...'. (It is better to use stderr than the default stdout for these messages.) 7/22/02
Beebe		 2nd
printing
minor Ch. 20, p. 465 In the last entry in Table 20-2, change "quantit y(plus" to "quantity (plus" (spacing error). 7/22/02
Beebe		 2nd
printing
minor Ch. 21, p. 469 In the second line, change "designed by" to "designated by". 7/22/02
Beebe		 2nd
printing
minor Ch. 21, p. 472 The title of Section 21.4 has some incorrect spacing.

Also, in the line just before the Example, change "accessing arrays elements" to "accessing array elements".

 5/27/02
Pöschl
7/22/02
Beebe		 2nd
printing
minor Ch. 21, p. 474 The title of Section 21.7 has some incorrect spacing 7/22/02
Beebe		 2nd
printing
severe Ch. 22, p. 481 Add Section 22.5, Floating-Point Expression Contraction (see below) 7/22/02
Spector		 2nd
printing
minor Ch. 24, p. 489 The title of Section 24.1 has some incorrect spacing. 5/27/02
Pöschl		 2nd
printing
minor Ch. 24, p. 491 The title of section 24.3 has some incorrect spacing. 5/27/02
Pöschl		 2nd
printing
moderate Index, p. 521 Add entries for:
const type qualifier 89
FP_CONTRACT pragma 481
volatile type qualifier 91		 7/22/02
Goodwin		 2nd
printing

Longer Corrections

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

Page 253 (Order of Evaluation)

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 313 (Reserved Identifiers)

Section 10.1.1: C99 is more specific about what identifiers are reserved for future library expansions. Although some identifiers are reserved for expansion in specific header files or for specific purposes only, it may be safer to avoid them entirely. Here is a complete list of all identifiers it is wise to avoid.

 Pprogrammers and C implementers should avoid the following identifiers in order to remain maximally compatible with current and future versions of C and its libraries:

  • C keywords, plus bool, true, and false
  • identifiers used in any of the present libraries
  • C++ keywords (to remain compatible with C++)
  • identifiers beginning with is, to, str, mem, or wcs and a lowercase letter (so isABigThing and is_a_big_thing are OK to use, for example)
  • identifiers beginning with PRI or SCN and either a lowercase letter or X
  • identifiers beginning LC_, SIG, or SIG_ and an uppercase letter
  • identifiers beginning int or uint and ending with _t
  • identifiers beginning INT or UINT and ending with _MAX, _MIN, or _C
  • identifiers beginning with E and either a digit or an uppercase letter
  • identifiers cerf, cerfc, cexp2, cexpm1, clog10, clog1p, clog2, clgamma, and ctgamma, optionally followed by f or l (ell)
  • identifiers beginning __STDC_
  • lowercase letters as I/O conversion specifiers or as character escape sequences
  • pragmas whose first preprocessing token is STDC

The only identifiers that are safe for a C implementation to use for extensions include:

  • identifiers beginning with _, as file scope identifiers and tags (e.g., as local or file scope variables)
  • identifiers beginning with _ and either a second _ or an uppercase letter (except __STDC_...), for any purpose (e.g., as macros, keywords, or global variables)
  • uppercase letters, as I/O conversion specifiers or as character escape sequences

C programmers can use any identifier not listed above.

Page 333

The synopsis should be:

#include <iso646.h>  
#define and &&
#define and_eq &=
#define bitand &
#define bitor |
#define compl ~
#define not !
#define not_eq !=
#define or ||
#define or_eq |=
#define xor ^
#define xor_eq ^=

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 481 (FP_CONTRACT pragma)

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

This page was last updated 2002-08-20 19:28 -0400.