C All-In-One Errata

Page 12: In the third-to-the-last paragraph, the last two words (in parentheses) read "course code" where it should say "source code."
Page 43-44: The code for oops.c contains several intentional errors. One not addressed in the text is the return statement without a return value. The code should read:; return(0);; at Line 6. The compiler will catch this omission as an error.
Page 51: Second to last paragraph, (bottom left in the box), should read, "The bottom line is that it takes more work for the computer to figure out floating point problems than it does for the computer to work in integers."
Page 67: In the first paragraph below the box, the range for a char is from -128 through 127, not -127 through 128. The values are properly displayed in Appendix E.
Page 74: At the end of the first diamond bullet, it should say atoi not atio. Think "A toy."; In the bottom paragraph, the "Tip," the fourth sentence should read, "Sometimes this strategy makes the code less readable for beginners, but it often improves readability for those more experienced in C."
Page 75: In exercise 1.5.6, there are 2.54 centimeters per inch. Also see the entry for page 689.
Page 76: The code for subjects.c, Line 10 should read:; scanf("%s",subname);; An ampersand is not needed before a string (or any array) in the scanf() function.; Later on the same page, I write, "The variable must be prefixed by an ampersand." That's technical incorrect. Arrays don't need the ampersand prefix. It doesn't screw anything up by adding them, but the statement I wrote implies something else. Bottom line: for strings or arrays, there is no need to prefix them with a & when use in scanf() functions.; (Also see the entry for pages 365 and 366.)
Page 77: In Table 5-1, the description for the getchar() function states that it returns a char variable. It returns an int.
Page 101: The tickets.c program uses the total variable without first initializing it. On some systems, this has the effect of producing an invalid result. Using a variable without initializing it is wrong. Sometimes it does work, but there is no guarantee. (Refer to pages 53 & 54 in the book.); To fix the program, add a new line below the variable declarations and above the first puts() statement:; total = 0;
Page 120: The line at the bottom of the page should read "The += mathematical shortcut . . ." The operator is listed as =+, which is incorrect.
Page 121: The source code demonstrates multiplying a variable by a value and then having the result placed back into the same variable. It doesn't not demonstrate multiplying a varible by its own value.
Page 130: The result of an operation such as a=b is not "always TRUE" as it says in the box. It could be TRUE or FALSE. The result depends on the value of b, which is assigned to a and evaluated by if. So when b is non-zero, the result is TRUE. When b is zero, the result is FALSE. Regardless, the point made in the sidebar is correct: you need two equal signs to compare values, not one.
Page 132: Modify line 13 to read like this:; if(agent==7 && (code=='B' || code=='b')); This modification ensures that the first two items (7 and B) aren't compared first, which they would be given the order of precedence.
Page 155: The hex code for the Yen character (¥) is 0x9D, not 0x9E as listed in the text. Even so, don't expect the code to work for your terminal; not every terminal uses the same code page.
Page 156: In the paragraph before the Base 8, or octal heading, the reference should be to Appendix B, not Appendix C.
Page 161: The third to last paragraph should reference exercise 2.2.4.
Page 197: The definition for OMEGA is incorrect. It results in the value 25, not 26. So the letter Z is never generated. To fix that, you need to change line 7 to read:; #define OMEGA ('Z' - '@'); The @ symbol has an ASCII value one less than 'A' (64 versus 65), so the end result is that all 26 letters of the alphabet will be produced by the code.
Page 212: The ff at the bottom of the page is supposed to be if, as in:; if(a > b) z = a; else z = b;
Page 219-220: The source code listed in the section Where goto Is Perhaps Needed, is missing the updates mentioned in the text. The code is found here.
Page 239: At the end of the three dimensional array, the value 108 shouldn't have a trailing comma. That could cause problems.
Page 242: In the first two bullets, the variable b should be variable ball.
Page 247: The last sentence before the section The Truth About Strings should read, "Before that, you have to understand that a string variable in C isn't a variable at all." The word "string" was omitted; string variables are character arrays.
Page 250: The char variable ch is declared in the code, but isn't used. The variable was a holdover from an earlier version of the program sushi.c.
Page 251: In the code example for copying a string at the bottom of the page, it's the contents of string org[] that are duplicated (copied) into string copy[]. I use the terms "first string" and "second string" which is confusing given the order of org[] and copy[] in the code example.
Page 252: In the third paragraph, the word doop should be copy. You use strcopy() to duplicate the string org to the string copy, as shown in the second paragraph on the page.
Page 277: The character array input is declared but never used. This mistake is also found on the source code listing for page 280.
Page 280: See the errata for Page 277 (above).
Page 281: The alternative methods for declaring structure variables use examples mystuff and hisstuff, but in the original code the variables are named my and his.
Page 285: There should be a backslash after this line in the code listing:; printf("%-18s\t%3d\t-15s\n",; Your compiler may not care if the backslash is missing or not. The publisher's DTP software often gobbles the backslash, which is why is was omitted in the text. (The sample code has the backslash.)
Page 288: The sample output of oz.c (oz6.c in the source code repository) is incorrect. The output shown is what the list looks like before the swap. After the swap, the output should look like this:
Page 308 and 309: The character array input is declared but never used in the two mystuff.c source code examples.
Page 312: The first paragraph in the "Roll 'dem bones!" section refers to the roll() function. It's named the throw() function in the code.; Last line, the variable c need not be declared; it's not used in the code.
Page 314: The throw() function in the craps.c code can confuse the compiler if it's set to compile C++ code and not ANSI C. That's because throw is a reserved word in C++. Often times this problem can be fixed as long as you use the .c extension for your source code file. If not, you'll need to adjust the compiler's options so that C code is produced, not C++.
Page 332: The character array input is declared but never used. in the mystuff.c source code.
Page 338: There are some missing escape characters in the code, which is common in For Dummies titles because the publisher's DTP software has trouble dealing with backslash characters.; In the final two puts() functions, the escape sequents should be \n. The n is missing.
Page 343: The scanf() statement is missing a & before the you.inches variable. It should read:; scanf("%d",&you.inches);; The two printf() statements at the end of the program use the %f placeholder incorrectly. They should read, both in the code and later on toward the end of the page:; printf("You are %.1f centimeters tall.\n",you.centimeters); printf("Paul is %.1f centimeters tall.\n",paul.centimeters);; Note that the code found here does list the correct expressions.
Page 356: Near the end of the code a capital I appears where a little i should be used instead. At the end of the code, the end of the line just before return(0) should be &temp[i];; Incidentally, many professors recommend that you not use i alone as a variable name for this reason, as well as that I is often visually confused with the number 1.
Page 359: The 11th line of the code should read:; kilometers = miles*KPM;
Page 362: Same item as on page 359: The 13th line of the code should read:; kilometers = miles*KMP;
Page 365: The sidebar at the bottom of the page, "If you don't need an & to read an array's address in C, why does scanf() still need an & in order to read a string" is incorrect. Disregard it.
Page 366: In the second paragraph, the parenthetical statement is incorrect. You do not need to use an & when specifying strings (char arrays) in a scanf() function.
Page 367: Line 6 in the code should read:; short int *pa;; Obviously if *pa is to reference the short int array variable they must be of the same type.
Page 388: In the paragraph that starts "That's 0x6B..." (in the middle of the page), the bits are marched to the right, not to the left.
Page 389: Another example of my left-right confusion: In the first paragraph in the section The Official >> Format, I use the word "left" when it's really right.
Page 392: The hex variable should be declared as a unsigned int. The word short throws some compilers because the %x conversion character (in line 8) expects an unsigned int, not an unsigned short int.
Page 393: Line 11 in the code should read:; upper >>= 8;; There is a space between the >> and equal sign, which leads to a compiler error.
Page 407: The sentence in the middle of the page should reference pointer variable c and not p:; This type of construction shouldn't be entirely alien to you. You should recognize that *c is a pointer, which means that c contains a memory address.; In the last paragraph, the * actually binds to a variable tighter than the ++. So in *p++, the value is read first, then the memory location is incremented.
Page 408: This sentence is incorrect:; In the case *p++, the ++ operator is higher on the list so it increments memory location p one chunk before the * operator fetches a value.; The *p part of the operator is bound more tightly than the ++, as described (correctly) in Table 4-1.; Also, it is unnecessary to add the c++; statement to the code.
Page 414: In the paragraph below the statement *a + 5, the second sentence should read, "If *a points at the first array element and the value of that element is zero . . ." The first array element is zero in C. In the example, I'm referring to the value of *a.
Pages 431 and 432: The array sample at the bottom of page 431 gives C:\> as an example. That's not really correct, as the \ character is an escape in a string. Therefore, to properly show that prompt, it should be listed as C:\\>. This has an effect on Figure 6-2 on page 432. If the prompt were really C:\\>, then the Figure 6-2 is correct.
Page 435: The first array in the code, dwarf, shows a comma after the last element, "sleepy". There should be no comma at that point in the declaration. The source code file on this site does show the proper format.
Page 440: In Figure 6-5, the *(*(array+0)+0) notation above bashful\0 is repeated. It should instead read *(*(array+0)+0), *(*(array+0)+1), *(*(array+0)+2), and so on.
Page 443: In Table 6-1, the last entry is incorrect. The 1 should be replaced with the letter a, like this:; **(array+a)+b is the same as array[a][0]+b which translates as the value of the first item in the array referenced by a, plus the value of b. Note that b is not used to calculate an address, but rather it's added to the value found at the address.
Page 459: The second bullet point should read variable *p and not *g. The placeholder VALUE is used in the first part of the program, not in the function. So *p is the variable being replaced.
Page 468: The solution for Exercise 4.7.4 is wrong. See the entry for Page 739.
Page 480: In the first paragraph (after the sidebar), the sentence "The random output sort of proves this" isn't necessarily correct. The free() function merely releases memory, making it available for re-allocation. It does not zero out that memory or fill it with random information. It could, which it did on my computer, but it might just end up still containing the same data. That data can and will be overwritten if something else grabs that chunk of memory with another malloc() function.
Page 504: Some versions of gcc recognize select() as an existing function — and it is! It's used for "synchronous I/O multiplexing" (whatever that is). So with some compilers you may need to rename the select() function as listed on page 504 in the main() function. I recommend using bselect() instead:; bselect();; On page 505 in lottoh:; void bselect(void);; And in SELECT.C on page 507:; void bselect(void); You do not need change the name of select.c, only the name of the function select().
Page 536: My editor got a bit overzealous when correcting the PigLatin program's output. Each word is Initial Caps in the output. The output should read:; Something clever Omthingsay Levercay; If you'd like to have the code keep the same case as the input text, then feel free to make that modification on your own!
Page 555: The main() function should be declared an int type, not void. The source code on this site is written correctly.
Page 587: If you're using Mac OS X, then the stat() function appears to return zero for the file size in the fileinfo.c program. This is because OS X stores the file size in a long int. When you use %d to display the value, it probably shows zero because of the way a double-long is stored in memory. Use %lld instead:; printf("File size is %lld bytes\n",fbuf.st_size);; (Those are lower case L characters, not ones, in the placeholder.)
Page 626: The sample code was copied improperly. It should read index++; not index--; as shown in the middle of the page.
Page 644: The chunk of text needs to be inserted after the while(ch != 'Q') statement. The statement mentioned in the book is while(ch != 0), which is incorrect.
Page 673: Step 2 is different for Windows 2000, which uses a local documents folder as the main personal file storage thingy. So use this command instead:; cd "local documents"; (The double quotes are not optional.); You'll then see the prompt reflect this:; C:\Local Documents>; Thanks to reader Cort for pointing this out. Also, reader James notes that a My Documents folder can be found, though it's location is:; Documents and Settings\Administrator\My Documents; I apologize for this confusion; it's been a long time since I had a Windows 2000 computer to play around on.
Page 689: The code for yourdata2.c is incorrect at line 16. Because there are 2.54 centimeters per inch, the line should read:; height = height * 2.54;
Page 690: First line of code at the top of the page is not needed. It's a relic from the original program; the variable input isn't used.
Page 696: The answer for Exercise 1.8.3 (MOON4.C) uses the wrong placeholder to display the value of the SPEED constant. The %d placeholder should be used instead of %f. Line 14 in the source code should read:; printf("Traveling at %d kph, ",SPEED);
Page 720: The toupper() function is covered in Book III, Chapter 3.
Page 738: Line 11 in the code should read:; showArray(primes,elements);; I forgot to update the code to include the proper reference to variable elements.
Page 739: The answer for Exercise 4.7.4 didn't include the ugly *string++ thing. I have updated the source code on this site to reflect the proper solution (or one of many such solutions).