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.

Severity Location Description Date posted & Reviewer Corrected
minor back cover, first bullet "Revision" is misspelled as revison. 2/15/02
Harbison
 
minor Contents, p. xi The listed title for Section 15.12 is different from what appears on p. 401, but both are correct. 1/29/02
Harbison
 
minor Ch. 1, p. 7 The last line of the second paragraph of Section 1.3: "(Section 9.9 )" has an extra space before the right parenthesis. 8/20/02
Kovacs
 
minor Ch. 2, p. 22 Fourth line of second example: a space is missing after "name" in "nameerror_handler". 8/20/02
Kovacs
 
moderate Ch. 2, p. 23 In Table 2-4, the keyword inline should be marked as being new to C99. 8/20/02
Kovacs
 
minor Ch. 2, p. 23 In the References section before Section 2.6.1: there should be an additional reference, "_Imaginary 6.2.4". 8/20/02
Kovacs
 
moderate Ch. 2, p. 29 At the end of the first paragraph of text: the constants for infinity and NaN in math.h are new in C99. 8/20/02
Kovacs
 
moderate Ch. 2, p. 33 In the first line on the page, replace "The fourth string is the same as "Copyright 2000 Texas Instruments."; it does not contain a newline character between the 0 and the T." with: "The fourth string is the same as "Copyright 2000 Texas Instruments. "; it does not contain a newline character between the blank following the 0 and the T." 8/20/02
Kovacs

5/6/03
Tondo

 
minor Ch. 2, p. 33 In the second line of the second example beginning on the page, "address a block of memory" should be "address of a block of memory". 8/20/02
Kovacs
 
minor Ch. 2, p. 39 In Table 2-8, the font used for the keywords is inconsistent with the rest of the book, and the ordering of the keywords is not consistent with Table 2-4. However, the information in the table is correct. 8/20/02
Kovacs
 
minor Ch. 3, p. 46 The example on this page is correct, but misses the point. Better would be to write
#define prod(x,y)  x*y
and then show that prod(5,a+b) ends up as 5*a+b, which is evaluated as (5*a)+b rather than the expected 5*(a+b).
3/18/04 Shulman  
moderate Ch. 3, p. 60 In the first example, the identifier IncludeFile is also spelled Includefile. The capitalization should be the same throughout. 5/4/03
Kovacs
 
minor Ch. 3, p. 64 On the second line, there should be a space after the right parenthesis. 5/4/03
Kovacs
 
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
minor Ch. 7, p. 68 In the References section at the end of Section 3.7.1, the section number for CX_LIMITED_RANGE should be 23.3, not 23.2. 12/7/03
Torell
 
minor Ch. 4, p. 75 On the fourth line, "ch. 8" should be "Ch. 8". 5/4/03
Kovacs
 
minor Ch. 4, p. 77 The References section should include references to "sizeof operator 7.5.2," "static storage class 4.3,"  and "typedef 5.10." 5/4/03
Kovacs
 
minor Ch. 4, p. 79 The References section should contain a reference to "external names 4.2.9." 5/4/03
Kovacs
 
minor Ch. 4, p. 85 In the adjust function, change "is" to "are" in the comment at the beginning.

Five lines further on, the comment should read "v[j] is the same as b[j+1]."

12/14/03 Low
3/18/04
Shulman
 
minor Ch. 4, p. 88 In the last line, the comment "extra" means "extraneous", but extraneous wouldn't fit on the line. 12/14/04 Low  
minor Ch. 4,
p. 89
In the 2nd paragraph of 4.4.3, clarify the meaning by changing "When used in a context that requires a value rather than a designator, the qualifiers are eliminated from the type." to "When used in a context that requires a value rather than a designator, the qualifiers are eliminated when determining the type of the resulting value." [An example would be good, too.]
8/21/05
Bezem
 
minor Ch. 4, p. 95 On line 11 in the signature of add, it would be clearer to declare op1 and op2 to be "const int * restrict". 3/18/04 Lupton  
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. Traditional C required all initializers to be constant expressions. C89 permitted nonconstant initializers for non-aggregate, automatic storage objects. C99 further permitted nonconstant initializers for aggregate, automatic types. 5/27/02
Hedquist

12/7/03
Torell

(previously listed as fixed in the 2nd printing, but it was not)
minor Ch. 4, p. 106

In the fourth line from the bottom of the page, the phrase "and an integer constant expression" should be "yields an integer constant expression." The text is correct as is, although it could be phrased more clearly.

5/5/03
Low

8/21/05
Torell

 
moderate Ch. 4, p. 108 In the first example, the second declaration of ary should be  "float ary[5] = ...". 3/18/04 Shulman  
minor Ch. 4, p. 116 In the last line of the first paragraph, change "Windows" to "Microsoft Windows". 12/14/03 Low  
minor Ch. 4, p. 124 In Table 5-1, footnote b ("New in C99") should apply to all types involving _Complex or _Imaginary. It should also be on the long long type. 8/11/06
Spector
 
minor Ch. 4,
p. 133
Reader requests a brief discussion of when NANs are produced. 8/21/05
Torell
 
minor Ch. 5,
p. 135
Spector writes: "It would help if you could provide a simple example or two of using the _Complex data type in section 5.2.1. Especially including using formatted I/O operations such as printf and (especially) scanf routines. [Also 5.13.4 and C99/C++ compatibility.] "
8/21/05
Spector
 
moderate Ch. 7,
p. 140, ...
The book's treatment of "lvalue" is not completely consistent, mixing the traditional C and Standard C definitions. See the explanation below. 8/21/05
Torell
 
minor Ch. 5, p. 143

In line 4 of Sec. 5.4.4, the sentence, "The result of & is a pointer to (the first element of) the array." might be more clearly written: "The result of & applied to an array name or other array value is a pointer to the first element of the array. In the expression &a[i], the & operator is actually applied to a[i], not a, since the subscript operator has higher precedence than &.

Torell states:"...in section 5.4.1 you made the point that &a is a pointer-to-array-of-T, which is not type compatible to &a[0] (pointer-to-T) (even though the actual pointer values should be the same). The reader should be aware that both "a == &a[0]" and "*a == a[0]" will compile successfully and will yield a "true" result, while "&a == &a[0]" will not compile without casting "&a" to a pointer-to-array-element."

5/5/03
Low

8/21/05
Torell

 
minor Ch. 5, p. 145

In the third line of the second example, replace "innermost" with "first" to avoid any possible confusion.

In the second prototype in that example, the name m is not a misprint; it is some non-constant integer variable other than n. A comment should be added to that effect.

3/18/04 Shulman

8/21/05
Torell

 
minor Ch. 5,
p. 151
In the last paragraph of the first example, the phrase "...in the first line it is necessary to hide..." should be "...in the first line is necessary to hide...." 8/21/05
Torell
 
minor Ch. 5, p. 160

In the first line on this page, change "then the L" to "then L".

The example line "struct S v;" should be "struct Vec v;" .

3/18/04 Shulman

8/21/05
Torell

 
minor Ch. 5, p. 174 In the example in the middle of the page, there are some spacing problems in comments. 5/4/03
Schoen
 
moderate Ch. 5, p. 176 The first sentence of Section 5.12 says there are only two situations in which the programmer uses an abstract declarator—cast expressions and type arguments to sizeof. There is a third situation: declaring parameter types in the prototype of a function declaration (Table 4-5). 5/5/03
Langbein
 
moderate Ch. 5, p. 178 In the seventh line of the first example, change "(enum e) 3" to "(enum e) 2", since the issue is casting a proper value for the enumeration. 3/18/04 Shulman  
moderate Ch. 5, p. 180 In the fourth line of Exercise 7, change "right-to-left" to "left-to-right". (Big endians are left-to-right.) See also p. 517 for a correction to the answer to the exercise. 3/18/04 Shulman  
minor Ch. 6, p. 188 In the second line of Section 6.1.6, change "that holds object" to "that holds an object". 6/4/03 Malcolm  
minor Ch. 6, p. 190 In the first line of the second paragraph, change "of the new type" to "in the new type." 3/18/04 Shulman  
minor Ch. 6, p. 194 In Table 6-2, the next to the last row, change "array ofT" to "array of T". 6/4/03 Malcolm  
minor Ch. 6, p. 197 In the last line of the page, there is a spacing problem in the expression "a + 1". 6/4/03 Malcolm  
minor Ch. 7,
p. 208
In the first example of section 7.3.1, change "four" to "three" in two places. 8/21/05
Torell
 
moderate Ch. 7, p. 211 In the second example, int matrix[10[10] should be double matrix[10][10]. 6/4/03 Malcolm  
minor Ch. 7,
p. 218
In the paragraph before the second example, change "execution" to "evaluation" in two places. 8/21/05
Shulman
 
moderate Ch. 7, p. 219 In the example at the top of the page, remove extra right braces at the end of  five lines. 12/7/03
Low
 
minor Ch. 7, p. 225 In the fourth line, there is a spacing problem in the expression i = *a. 3/18/04 Torell  
moderate Ch. 7,
p. 231
In the next-to-last line of the 2nd full paragraph, change p-q to q. 8/21/05
Shulman
 
minor Ch. 7, pp. 239243 The captions below the listings of the SET example have some spacing problems in them. 5/4/03
Goh
 
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. 241

The five pages of the SET example are not on consecutive pages. The final page should be on p. 242 but instead is on p. 243. (See the Examples page on this site for all the code.)

2/15/02
Harbison
 
minor Ch. 7, p. 245 In the footnote to Table 7-5, there is a spacing problem. 3/18/04 Torell  
minor Ch. 7,
p. 246
In the last line of the last example, a=(b=(d+7) should be a=(b=(d+7)). 8/21/05
Shulman
 
moderate Ch. 7, p. 249 In Section 7.10, Sequential Expressions, in the 4th line from the bottom of the page, delete the words ", after the usual unary conversions". The type and value of the comma expression are the type and value of the right operand; no conversions are applied to the right hand expression. 12/14/03
Sieburgh
 
minor Ch. 7,
p. 250
In the 2nd to last paragraph in Section 7.10, the phrase "field-length expression" means the constant expression that specifies the width of a bit field in a structure declaration. However, Standard C implementations may not permit a comma expression to be used as a constant expression, even if the discarded expressions are themselves constant. The Standard itself is ambiguous. 8/21/05
Torell
 
minor Ch. 7,
p. 252
In the first line of Section 7.11.2, change "bit field in a structure" to "bit field in a structure or union." 8/21/05
Shulman
 
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
severe Ch. 7, p. 254 In the paragraph beginning, "When evaluating the actual arguments in a function call,...", all the text beginning with, "but the effect will be as if..." should be deleted. Standard C does not guarantee that each argument to a function call is evaluated fully before other arguments are evaluated, nor are there guarantees for binary operators or array subscripting expressions. The example which follows the paragraph depends on behavior that is simply undefined by Standard C. 5/18/03
Rivilis
 

severe

minor

Ch. 7, p. 255

In Section 7.12.1, the list of sequence points is incomplete. The correct list is given in Section 4.4.5 on p. 91, which adds: when library functions return, after the actions of printf/scannf conversion specifiers, and around calls to comparison functions applied to bsearch and qsort.

In Section 7.13, the line "2. the first operand of a comma expression" would be better written "2. the left operand of a comma expression"; this means all but the last expression in a comma-separated list of expressions, if you follow the grammar.

5/18/03
Rivilis

8/21/05
Torell

 
moderate Ch. 7,
p. 268
In the third-from-last line on the page, change getchar(ch) to getchar(). 8/21/05
Shulman
 
moderate Ch. 7, p. 269

App. B, p. 504, 507 506

Change the definitions of for-expression and initial-clause as follows, moving the semicolon from the former to the latter to avoid doubling the semicolon when declaration is used in C99. (A declaration ends in a semicolon.) [This may still be confusing.]

initial-clause :
     expressionopt  ;
     declaration               (C99)

for-expression :
     ( initial-clause   expressionopt ; expressionopt )

In Step 1 of the description of the execution of the for loop, replace "then no action occurs" with "then nothing happens in this step."

12/15/03
Blake

8/21/05
Czapla

8/21/05
Shulman

 
minor Ch. 8, p. 279 In the paragraph following the example code in the middle of the page, change j<n to j<N. 12/14/03 Torell  
severe Ch. 8, p. 281 In the example, the two for loops have their condition and increment expressions interchanged. They should be:
for (i=0; i<N; i++)
  for (j=0; j<M; j++)
6/4/03 Malcolm  
moderate Ch. 9,
p. 292
In Section 9.2.3, step 3, second line: change "declaration" to "definition." 8/21/05
Shulman
 
minor Ch. 9, p. 293 In the next to last line of the first example, there is a spacing problem in the text "implements the definition of f." 6/4/03 Malcolm  
minor Ch. 9, p. 297 In the example code near the top of the page, change extern int g(const y[10]);
to extern int g(const int y[10]);
12/14/03 Torell  
moderate Ch. 9,
p. 312
In the example, only the second part, using #undef, should be shown. There is no reason to show the first one, which might not be legal (or portable) in Standard C. 8/21/05
Shulman
 
minor Ch. 10, p. 319 In the fourth column, the 7th and 8th lines should read isunordered and ldexp, respectively. 12/14/03 Low  
moderate Ch. 11,
p. 329

In the second paragraph following the synopsis in Section 11.3, change "#undefine" to "#undef" twice.

In Section 11.4, remove "type" from the synopsis of va_start.

8/21/05
Shulman

8/21/05
Shulman

 
minor Ch. 11, p. 330 At the end of the paragraph on va_end, replace "ap and va_alist" with "ap and va_alist (Section 11.4.1)". 12/17/03 Torell  
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
moderate Ch. 11, p. 339 In the Synopsis, the argument to isprint should have type int, not char. 12/14/03 Low  
moderate Ch. 12, p. 335

At the end of the second paragraph, change "generalized classification functions wctrans and iswctrans" to "generalized classification functions wctype and iswctype." Also, at the end of the introduction to Ch. 12, add references to wctype 12.10 and wctrans 12.11.

In the last paragraph, beginning "All the facilities described here...": Only values representable as type unsigned char (not char in general, which may be signed) plus the EOF value are guaranteed to be handled correctly. (Thus no negative values except perhaps EOF.) For wide characters, all values of type wchar_t between WCHAR_MIN and WCHAR_MAX are handled correctly, plus the WEOF value (which is of type wint_t and is not a value between WCHAR_MIN and WCHAR_MAX).

12/17/03 Torell

8/21/05
Olson

 
minor Ch. 12, p. 338 In the Synopsis for iscsym and iscsymf, type of the arguments should be int, not char, according to present (non-Standard) usage. 12/17/03 Torell  
minor Ch. 12, p. 339 In the Synopsis, change the argument of isprint from char c to int c. 3/18/04 Torell  
moderate Ch. 12,
p. 341
In the last line of Section 12.6.1, change ispunct(c) to iswpunct(c). 8/21/05
Shulman
 
minor Ch. 12, p. 344, 345 In the References section at the end of 12.10 and 12.11, change "LC_CTYPE 11.5; locale 11.5" to "LC_CTYPE 20.1; locale Ch. 20". Also add locale to the References sections in  the introduction to Ch. 20 and in Sections 12.5 and 12.6. 12/17/03 Torell  
severe Ch. 13, p. 348 In the fifth line from the bottom of the page, this sentence appears: "If the value of n is zero or negative, then calling strncat has no effect." In fact, a "negative" value of n will be treated as a positive value because size_t is an unsigned type. This error also occurs in the descriptions of strncmp and strncpy, and is a holdover from traditional C, when the type of n was int. Failure to guard against "negative" counts can result in buffer overrun errors. 5/4/03
van der Wal
 
minor Ch. 13,
p. 348, 349
In the synopses of Section 13.1 and 13.2, change wchr.h to wchar.h. 8/21/05
Davis
 
severe Ch. 13, p. 354 The description of strtok is incorrect in this respect: Every time strtok is called, any separator characters at the beginning of the search string are skipped to find the beginning of the next token. 5/17/03 Torell  
minor Ch. 13, p. 356 In the fifth line of the first paragraph of Section 13.10, change "setlocale, Section 11.5" to "setlocale, Section 20.1".
In the sixth line of the third paragraph of Section 13.10, change "contents of dest" to "content of dest."
12/17/03 Torell
12/7/03
Low
 
moderate Ch. 14,
p. 362
The val argument to wmemset should have type wchar_t, not int. 8/21/05
Shulman
 
moderate Ch. 15, p. 367

At the top of the page, the header file string.h should also beW included since the strerror function is used.  Also, minor, in the sixth line from the bottom of the example, "ingore" should be "ignore."

The description of fflush needs this addition: If the stream argument is null, fflush will perform the flushing operation on all open streams for which the fflush operation is appropriate.

6/4/03 Malcolm

8/21/05
Barthel

 
moderate Ch. 15, p. 370 The fourth line of the Section 15.3 synopsis is garbled. It should read:
    char * restrict buf,
12/10/03 Yerem  
minor Ch. 15,
p. 378
In the 3rd category of the contents of a control string, change "or a percent sign" to "or a conversion specification"; that is, all character in a conversion specification have special meaning. 8/21/05
Shulman
 
minor Ch. 15, p. 380 In Table 15-3, the size specifiers hh, ll, j, z, and t should all be footnoted as new in C99.
Also, the table could be formatted more clearly: It is to be understood that any of the conversion letters in each section of the table can be combined with any of the size specifiers in that section. The conversions d and i are together in the first section, and u, o, and x are together in the second section.
12/17/03
Torell
 
minor Ch. 15, p. 383

In the second line below the table, change "that are not whitespace" to "that are not whitespace (subject to the maximum field width)".

In the last paragraph on the page, the description of floating point constant formats is wrong. There cannot be "no digits" before the exponent part, and there cannot be "no digits" following the letter introducing the exponent; both must be non-empty.

12/17/03 Torell

8/21/05
Carlini

 
moderate Ch. 15, p. 384 In the description of the [ conversion, we should note that it is a common extension (e.g., by Microsoft) to allow a range of characters to be specified with a hyphen. For example, [a-z] would mean the same as [abcdefghijklmnopqrstuvwxyz].

Also, the [ conversion must match at least one input character or else the conversion fails.

12/17/03 Torell

3/18/04
Torell

 
moderate Ch. 15, p. 387 In Section 15.11, the information on snprintf and swprintf is incomplete, in particular about how the buffer count is handled. In both functions, if the specified buffer size is n and n>0, then a maximum of n-1 output characters are written and are always followed by a terminating null character. If n=0, then nothing is written and zero is returned. The return values are different: snprintf returns the number of characters that would have been written if n had been sufficiently large to hold them all, so if the return value is less than or equal to n, then the buffer was too small. swprintf returns the number of characters that actually were written, or a negative value if n was not large enough. The Standard's description of snprintf is specific: the behavior is as if the entire output string were calculated and then the characters that don't fit into the buffer were discarded. If n=0, then the buffer pointer may be null. 6/4/03 Yerem  
moderate Ch. 15, p. 390 In the last line of the section titled The 0 flag, replace "even if the - flag is present" with "even if the 0 flag is present". 5/5/03
van der Wal
 
minor Ch. 15,
p. 392-400
In several descriptions of conversion operations, the text says that certain flags or specifiers "are not relevant." Instead, it should say that they "have no effect," which was the intended meaning. 11/11/03
Torell
 
minor Ch. 15, p. 393 To clarify an apparent inconsistency: The behavior of the 0 conversion flag is undefined for the c and s conversion operations (as shown in Table 15-6), but some libraries do perform left-padding with zeros when it is present (as shown in Tables 15-12 and 15-14).

Also, Table 15-6 does not list many of the size modifiers discussed in Section 15.11.6, including ll, hh, j, z, and t.

In Table 15-6, list the F conversion with the f conversion.

5/4/03
Molle

3/18/04 Torell

8/21/05
Shulman

 
moderate Ch. 15, pp. 394-5 In Table 15-8, the output of 45 under conversion %14u should be right-justified. It appears that a blank is missing.
In Table 15-9, the output of -45 under conversion %-14o should be 37777777723, left justified. There is an extra 7 in the output shown.
In Table 15-10, the output of -45 under the conversion %-#12.4x should be 0xffffffd3, left justified. The output shown does not have the leading 0x.
5/5/03
Molle,
van der Wal

12/7/03 Torell

 
minor Ch. 15,
p. 396
At the end of the first paragraph, the reference to Table 15-13 should be to Table 15-11. 8/21/05
Shulman
 
moderate Ch. 15,
p. 397
In the description of the n conversion, several size modifers are not discussed: hh means the argument is of type signed char *; ll signifies type long long int *; j signifies typeintmax_t *; z signifies typesize_t *; and t signifies typeptrdiff_t *. No other size modifers are permitted. 8/21/05
Torell
 
moderate Ch. 15, p. 401 The text omits mention of the vsnprintf function, which is analogous to the snprintf function and has the signature: int vsnprintf(char * restrict s, size_t n, const char * restrict format, va_list arg). 6/4/03 Harbison

12/7/03
Torell

 
moderate Ch. 15,
p. 403
In the example, the call to fopen should use the "rb" (binary) mode instead of "r" (text), since it is binary data that is being read. 8/21/05
Goh
 
minor Ch. 16,
p. 407
The heading for section 16.1 should include realloc. 8/21/05
Torrell
 
minor Ch. 16,
p. 410
In the second sentence of the second paragraph of section 16.1.1, change "new versions of the allocation functions" to "the mlalloc, clalloc and relalloc functions." 8/21/05
Torrell
 
minor Ch. 16, p. 411 In the title of Section 6.3, there is an extraneous "l" at the end of the list of functions. This also appears in the page heading and the table of contents. 6/4/03 Malcolm  
minor Ch. 16, p. 416

In the second line from the top of the page, change env to envp.

Section 16.7.1 mentions the UNIX exec family of functions, which are not part of Standard C. Other useful functions, particularly fork, are not mentioned. Remove the detailed descriptions in favor of a reference to where standard Posix definitions may be found, e.g.,
http://www.opengroup.org/onlinepubs/007904975/functions/contents.html

8/21/05
Torell

12/7/03
Low

 
minor Ch. 16,
p. 418
In the second line from the top of the page, remove the reference to Section 20.6. 8/21/05
Torell
 
minor Ch. 16,
p. 421
In the last paragraph in section 16.10.1, replace the reference to "Section 11.5" with "Section 20.1." 8/21/05
Torell
 
moderate Ch. 16,
p. 423
In four places on this page, change src to s. 8/21/05
Shulman
 
moderate Ch. 17, p. 426 The C99 math_errhandling facility is not described in the book. In the first paragraph beginning on the page, delete the last sentence, which begins "C99 allows considerable flexibility...". Insert just before Section 17.1 the information below. 12/14/03 Low  
minor Ch. 17,
p. 428
In the synopsis, remove the two occurrences of C99 at the end of lines. Also, the last three functions could be better formatted. 8/21/05
Shulman
 
moderate Ch. 17, p. 430 The logb, logbf, and logbl functions are missing from the Synopsis of Section 17.6. They are:
double logb(double x);
float logbf(float x);
long double logbl(long double x);
12/7/03
Low
 
moderate Ch. 17, p. 431 At the end of Section 17.6, add a new paragraph: "The log1p(x) functions return log(1.0+x), and are expected to be more accurate than log when x has a very small magnitude."
Also add log1p to the index.
7/20/03
Low
 
minor Ch. 17,
p. 435
The function signatures in the Synopsis for Section 17.11 are in the wrong font (size). 8/21/05
Torell
 
severe Ch. 17, p. 436 In the example, change "float" to "double" and "double" to "float". 12/7/03
Low
 
minor Ch. 18,
p. 449
In the heading on Table 18-2, change "strftime" to "strftime and wcsftime." 8/21/05
Shulman
 

minor

moderate

Ch. 19,
p. 456

The heading for Section 19.6 omitts the kill function.

The type sig_atomic_t is not discussed. It is an implementation-defined integer type, and accesses of objects of that type cannot be interrupted by the underlying hardware. The definition may include the volatile qualifier.

8/21/05
Torell

8/21/05
Torell, Shulman

 
minor Ch. 19,
p. 457
In the example on this page, the line "void (*old_handler)();" should be replaced by "void (*old_handler)(int);." 8/21/05
Torell
 
minor Ch. 21, p. 475 In the title of Section 21.8, "strtouimax" should be "strtoumax." 6/4/03 Malcolm  
moderate Ch. 21,
p. 480
In the third paragraph, change "flagp*" to "*flagp" in two places. 8/21/05
Torell, Shulman
 
severe Ch. 22, p. 481 Add Section 22.5, Floating-Point Expression Contraction (see below) 7/22/02
Spector
ü2nd
printing
minor Ch. 23,
p. 485
Torell writes: "It would be helpful in sections 23.4 - 23.7 to remind the reader about the existence of type-generic macros, as is done in the appropriate sections of chapter 17." 8/21/05
Torell
 
moderate Ch. 24,
p. 493
In the first parameter to wcstoul and strtoull, char should be wchar_t. Also, strtoull should in fact be wcstoull. 8/21/05
Shulman
 
minor Ch. 24,
p. 495
In the first line (after the tables), change wctrans_t to wctrans. 8/21/05
Shulman
 
minor App. A, p. 497 In the first row of the table, for the ASCII code 0, the entry in the Name column should be changed from "NUL" to "NUL, \0", since \0 is the escape for the null character. 12/14/03 Low  
moderate App. B, p. 505 In the grammar defining identifier-list, replace parameter-list with identifier-list, so that the production agrees with the one on p. 287. 8/22/06
Legris
 
minor App. C, p. 513 Clarifying the answer to 2(h): An implementation could, as a language extension, accept $ as an identifier character, in which caset the token would be valid. 5/5/03
Tondo
 
moderate App. C, p. 514 The answer labeled 6(d) is, in fact, the answer to question 6(b) on p. 42. The answer labeled 6(b) belongs to a question in a previous edition that was deleted. 5/5/03
Tondo
 
minor App. C, p. 514 In the answer to question 8, replace "the error message would always appear and halt compilation regardless of the value of x" with "the error message would always appear regardless of the value of x." Whether or not compilation is actually halted by #error is implementation-defined. 7/1/03
Torell
 
moderate App. C, p. 515 Answers to Ch. 4 exercises 6 through 10 are not included. I will post them here eventually. 1/29/02
Harbison
 
severe App. C, p. 517 In the answer to Ch. 5, exercise 7, in the Big-Endian sketch:  Change "right-to-left" to "left-to-right" and change the order of fields m, e, and s so that s is to the right of  i, e is to the right of s, and m is to the right of e. 3/18/04 Shulman  
severe App. C, p. 517 In the answer to Ch. 5, exercise 8, the return value should be "(int *) 0". 3/18/04 Shulman  
minor App. C,
p. 518
Then answer to Ch. 8, Ex. 1(a) can also be written:
n = A;
L:
if (n < B) {
   sum += n;
   n++;
   goto L;
}

8/21/05
Shulman
 
moderate Index, pp. 521533 The keyword inline should appear in the index with a reference to pages 86 and 304.
The function log1p should appear in the index with a reference to page 430.
The unlink command should appear in the index with a reference to page 404.
The ldexp entry should point to page 429.
5/5/05
Lai, Brinkhoff, Trux

12/7/03
Low

 

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:

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