Errata

The scope of automatic variable is tied to block (any block, not only function block). If there is a subblock inside a function, for a variable declared inside, the statement "Their scope is restricted to the function" is not true.

Note from the Author or Editor:
Page 2
Automatic section

After:

"... the fuction is executing."

Add the following paragraph

"In general, the scope of variables declared within a block statement is restricted to that block. These are often referred to as automatic variables."

The text says "However, in the new C standard, C11, variable size arrays are supported.". While technically speaking this sentence is true, it suggest that variable size arrays are only supported by C11, not earlier language standards. Truth is, this feature was added in much earlier, C99 standard.

Note from the Author or Editor:
Page 4 - Replace the following sentence;

"However, in the new C standard, C11, variable size arrays are supported."

With:

"However, variable size arrays have been supported since C99.".

The following code:

printf("%p\n",*pi); // Displays 5

uses incorrect format specifier (i.e. %p) for displaying a (derefenced) value of int type, which invokes undefined behavior. The correct, UB-free version would be:

printf("%d\n",*pi); // Displays 5

Note from the Author or Editor:
Page 11
2nd paragraph
Change:

printf("%p\n",*pi); // Displays 5

To:

printf("%d\n",*pi); // Displays 5

A pointer to void will never be equal to another pointer.

? should be ? :

A pointer to void will never be equal to another pointer to void.

reasoning : a pointer to void can be assigned the value of a non-void pointer

Note from the Author or Editor:
On page 14, second bullet, add the following sentence:

The actual behavior of void pointers is system dependent.

There is no byte type in C. To represent entity of exactly one byte there is char type or its varations such signed char and unsigned char. All three are guranteed that sizeof(T) == 1 holds.

Note from the Author or Editor:
Page 21
Table 1-5. Data type sizes
Remove the first table entry: "byte 1"

In this section "pointers to short and char", which is just after figure 1-8 (page number of 22 is approximate because I was reading the kindle edition)

printf("Content of ps before: %d\n",ps);
ps = ps + 1;
printf("Content of ps after: %d\n",ps);

printf("Content of pc before: %d\n",pc);
pc = pc + 1;
printf("Content of pc after: %d\n",pc);

The use of the %d format specifier results in negative values on some platforms:
content of ps before: -272632754
content of ps after: -272632752
content of pc before: -272632769
content of pc after: -272632768
It should be replaced with %p specifier as the author uses on many other examples.

Corrected version:

printf("Content of ps before: %p\n",ps);
ps = ps + 1;
printf("Content of ps after: %p\n",ps);

printf("Content of pc before: %p\n",pc);
pc = pc + 1;
printf("Content of pc after: %p\n",pc);

Here's an example of the corrected output on my platform:
content of ps before: 0x7ffeefbff44e
content of ps after: 0x7ffeefbff450
content of pc before: 0x7ffeefbff43f
content of pc after: 0x7ffeefbff440

Note from the Author or Editor:
While the use of the %d specifier can result in a negative value on some platforms, it is not an error. However, to avoid confusion, please add the following statement:

If the results displayed are negative values, use the %p specifier instead.

Before the first sentence on page 23. That sentence starts with: "The ps pointer is ...

Thanks.

addr 116 should be labeled p1, addr 120 should be
labeled p2

Note from the Author or Editor:
On page 24 change the text in Figure 1-9 from:

p0 116
p0 120

to:

p1 116
p2 120

The array called "title" in Figure 1-10 should be named "titles".

The section is about pointers to a constant, but the text presents them twice as constant pointers.

1. "Dereferencing a constant pointer is fine if we are simply reading the integer's value"

This statement seems correct for both pointers to constant and constant pointers, but considering the section it is placed, shouldn't it be "Dereferencing a pointer to a constant is fine [...]"?

2. "We cannot dereference a constant pointer to change what the pointer references but we can change the pointer"

This statement seems incorrect for constant pointers, shouldn't it be "We cannot dereference a pointer to a constant to change what the pointer references [...]"?

Thank you!

Note from the Author or Editor:
The reader has some good ideas. On page 27, change the statement at the bottom of the page from:

"Dereferencing a constant pointer is fine ..."

To:

"Dereferencing a pointer to a constant is fine..."

On page 28, at the top of the page change:

"We cannot dereference a constant pointer to change what the pointer references but we can change the pointer."

To:

"We cannot dereference a pointer to a constant to change what the pointer references. But we can change the pointer."

Thanks.

The author introduces the malloc function and has given the relevant code for it. However, the given code will generate multiple warnings as the author has not mentioned to include <stdlib.h> before using the malloc function. This file includes the declaration of the function. I think this can be very confusing for a student.

Note from the Author or Editor:
Page 34
Dynamic Memory Allocation Section
Change the first sentence from:

The basic steps used for dynamic memory allocation in C are:

To:

The basic steps used for dynamic memory allocation in C are listed next. The functions are found in the stdlib.h header file.

The paragraph reads:
...In the following
example, an array of char is allocated for use in a function:
void compute(int size) {
char* buffer[size];
...
}

Either the description or the code is wrong. The code defines and allocates an array of pointers to char. The description "an array of chars is allocated" should be coded as: char buffer[size];

Note from the Author or Editor:
On page 46 change the following line of code:

char* buffer[size];

to:

char buffer[size];

The variable sum is a automatic variable and is not initialized. Based on the C standard:

If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate.

Even if we may get the correct result on some compilers, we should initialize it. So we should change

int sum;

to

int sum = 0;

Note from the Author or Editor:
On page 60, change:

int sum;

to

int sum = 0;

While the purpose of the example is to show the structure of the stack frame, this correction will ensure the proper execution of the function.

When the "subtract" function was renamed on page 74, several references to the function were not updated. The word "subtract" needs to be replaced with "sub" in the following locations:

Page 75:
Second paragraph of the section: Returning Function Pointer

"It will return a pointer to either the add or the subtract function"

First code sequence in that section:

" case: '-': retrun subtract;"

Page 76:
Third paragraph, last sentence:

"We will use this definition in conjunction with the add and subtract functions ..."

Fourth paragraph:

"... we will then assign the add and subtract functions ..."

Third code sequence:

" operations['-'] = subtract;"

....If the number of values is less than the size of the array, as in this example, the value is used to initialize every element of the array.

This doesn't appear quite correct to me ;
In my opinion the rule is that all array elements that do not have a corresponding initializer value , are initialized to 0 (or NULL in case of a pointer).
In the given example : operation operations[128] = {NULL} , the result of both interpretations is identical because a NULL value is used as the first initializer

Note from the Author or Editor:
On page 76, first paragraph, change the sentence reading:

If the number of values is less than the size of the array, as in this example, the value is used to initialize every element of the array.

To:

If the number of values is less than the size of the array, as in this example, then the remaining elements of the array are initialized to 0.

This looks like small oversight:

basePointer = (fptrToSingleInt)fptrFirst;

Since type of basePointer is fptrBase, which is type definition for void (*p)(), the correct cast would be:

basePointer = (fptrBase)fptrFirst;

The former cast gives me error with pedantic-errors flag:

$ gcc -std=c99 -pedantic-errors check.c
check.c: In function ‘main’:
check.c:16: error: assignment from incompatible pointer type

and the latter compiles just fine.

Note from the Author or Editor:
Page 78
Last code segement
Change:

basePointer = (fptrToSingleInt)fptrFirst;

To:

basePointer = (fptrBase)fptrFirst;

This will avoid a syntax error when using the -std=c99 and -pedantic-errors compiler flag with the gcc compiler.

"The notation vector+i generates machine code that starts at location vector, adds i to the address, and then uses the contents at this address."

"vector+i" should be replaced with *(vector+i) since later the sentence says, "contents at this address".

Note from the Author or Editor:
On page 85 in the second paragraph of the section titled, Differences Between Arrays and Pointers, change both occurrences of:

vector+i

To:

*(vector+i)

&vector[2] means go RIGHT 2 positions from vector and return that address instead of LEFT.

(right or left doesn't really matters, the fact is for for accessing vector[2] you use right direction from vector then for &vector[2] it have to be right too).

Note from the Author or Editor:
On page 85
First paragraph
Change the last sentence:

"It can be interpreted as go left two positions ..."

To:

"It can be interpreted as go right two positions ..."

The example given may contain undefined behavior due to the line "currentPosition = newBuffer + (currentPosition - buffer);" when the variable buffer is referenced after calling realloc.

This is extensively discussed at http://stackoverflow.com/questions/35047199/array-resizing-and-realloc-function

Note from the Author or Editor:
There is an interesting discussion of this problem found at: http://stackoverflow.com/questions/35047199/array-resizing-and-realloc-function. While not likely to occur in normal situations, the proposed solution as shown below will work:

if(++length >= maximumLength)
{
size_t currentOffset = currentPosition - buffer;

char *newBuffer = realloc(......
// ...

currentPosition = newBuffer + currentOffset;
buffer = newBuffer;
}

This is minor nitpick. The name of string variable in main does not match to Figure 4-7, which uses name "word" for it. Thus my suggestion is to replace:

char* buffer = (char*)malloc(strlen(" cat")+1);
strcpy(buffer," cat");
printf("%s\n",trim(buffer));

with:

char* word = (char*)malloc(strlen(" cat")+1);
strcpy(word," cat");
printf("%s\n",trim(word));

or either replace word with buffer in Figure 4-7.

Note from the Author or Editor:
Page 89
Code sequence
Replace the variable, buffer, in the main function with the variable, word, as shown here:

char* word = (char*)malloc(strlen(" cat")+1);
strcpy(word," cat");
printf("%s\n",trim(word));

This will match the variables used in Figure 4-7 on page 90.

The following:

printf("%d ", (arr+i)[j]);

does not evaluate correct offset for arr (as it does not "jump" into next row, but only to next integer element). The proper expression would be:

printf("%d ", (arr+i*cols)[j]);

Note from the Author or Editor:
Page 98
Third code segment
Change:

printf("%d ",(arr+i) [j]);

To:

printf("%d ",(arr+i*cols) [j]);

This will correctly address the correct element of the matrix array.

The code sample uses "layer1", while the output below prints "arr2". Hence my suggestion is to replace all three occurrences of:

printf("layer1[%d][%d]...

with:

printf("arr2[%d][%d]...

Note from the Author or Editor:
Page 104
Code sequence

Change the three occurences of:

printf("layer1[%d][%d]...

with:

printf("arr2[%d][%d]...

In the code example

char* path = "C:";
char* currentPath = (char*) malloc(strlen(path)+2);
currentPath = strcat(currentPath,"\\");

memory for "currentPath" is allocated, not initialized.
currentPath does not have anything even NUL terminator.
The result of strcat is unexpected.

This example needs copying path string to the
currentPath before invoking strcat, as follows.

char* path = "C:";
char* currentPath = (char*) malloc(strlen(path)+2);
strcpy(currentPath, path);
currentPath = strcat(currentPath,"\\");

Note from the Author or Editor:
On page 121, change the first code sequence to:

char path[] = "C:";
char* currentPath = (char*) malloc(strlen(path) + 2);
strcpy(currentPath,path);
strcat(currentPath, "\\");

This copies "C:" to currentPath first and then performs concatenation.

> In the second statement, the
> address-of operator is used explicitly. This is redundant and
> unnecessary. In addition, it will often generate a warning.

The type of &simpleArray is not "char *" but "char **", because address-of operator is applied to char* variable.

Result of passing &simpleArray to stringLength is not "redundant". It will end with imcompatible pointer warning.

Note from the Author or Editor:
Page 122, replace the sentences:

This is redundant and unnecessary. In additional, it will often generate a warning.

With:

While this will work, we are passing a pointer to a pointer to a char instead of a pointer to a char which will generate a warning .

The "char* format" function takes parameter "size_t size" which is used as the "size" argument to "snprintf", which is the size of the buffer the snprintf function writes to.

However the example showing the "format" function's use passes sizeof(buffer) to the function; if the buffer memory has been allocated via malloc, sizeof(buffer) will not be the size of the allocated buffer.

Note from the Author or Editor:
Page 124
The sentence before the second code sequence
Change:

"The following demonstrates the use of the function:"

To:

"The following statement demonstrates the use of the function. It assumes that buffer has been declared as an array. If the memory for buffer has been dynamically allocated, then the size of the memory allocated needs to be passed instead of using the sizeof function."

Returned value may not be necessarily equal to -1 or 1 as strcmp is defined to return value that is either zero, negative or positive.

The are two remedies, that I would recommend:

1) Reflect negative or positive values in main text (i.e. instead of -1 and 1)
2) Modify compareEmployee to:

int tmp = strcmp(e1->name, e2->name);
return (tmp > 0) - (tmp < 0); // sgn(tmp)

Note from the Author or Editor:
Page 142
Third paragraph
Replace sentences 5 and 6 with:

"A negative return value means the first employee preceeds the second employee alphabetically. A postive return value means the first employee folows the second employee."

The book claims that -Wall enables all gcc compiler warnings. This is actually wrong! There are more warnings to enable but all may not be useful. For example adding -Wextra will enable additional warnings that may be of value. For more info see man pages and/or http://stackoverflow.com/questions/11714827/how-to-turn-on-literally-all-of-gccs-warnings

Note from the Author or Editor:
Page 173
Using Static Analysis Tools Section
First paragraph

Change:

"For example, the GCC compiler's -Wall option enables the reporting of all compiler warnings."

To:

"For example, the GCC compiler's -Wall option enables the reporting of many but not all compiler warnings. Check the compiler's documentation for specific compiler options."

Code from the book:

char *name = (char*)malloc(...);
...
memset(name,0,sizeof(name));

The above will only set sizeof(char*) bytes to 0 rather than the actual number of allocated bytes.

Note from the Author or Editor:
Page 173
Second code segment
Change:

char* name = (char*)malloc(...);
...
memset(name,0,sizeof(name));
free(name);

To:

int SIZEOFFIELD = ...;
char* name = (char*)malloc(SIZEOFFIELD);
...
memset(name,0,SIZEOFFIELD);
free(name);

The line
double sum;

of code at the bottom of page 187 can be eliminated since that variable (i.e. sum) is never used in the program. On the other hand, however, the field 'sum' of the variable vectorInfo is not initialized (to 0). So the final part of the code should be

vectorInfo.vectorA = vectorA;vectorInfo.vectorB = vectorB;vectorInfo.sum = 0; //This line is missing in the original codevectorInfo.length = 4;

Both person instances are not freed, thus introducing a memory leak in the application. The suggested modification is to replace:

person = removeNode(list);
displayPerson(*person);

person = removeNode(list);
displayPerson(*person);

with:

person = removeNode(list);
displayPerson(*person);
free(person); // Potential memory leak!

person = removeNode(list);
displayPerson(*person);
free(person);

The reason is that removeNode by design does not free returned object. The comment is needed for exactly them same reason as in removeLinkedListInstance's body - Person struct might have pointer fields, that are allocated on the heap individually.

Note from the Author or Editor:
Page 193
Last code segment

The removeNode function will free up the memory allocated for the Node holding a Person. However, it does not and should not attempt to free up the data it holds. In this case, this is the Person.

It is the responsibility of the user to free up memory for the data. This is best achieved in this example by using the deallocatePerson function developed on page 138 similar to the following:

person = removeNode(list);
displayPerson(*person);
deallocatePerson(person);
free(person);

void rectangleSetY(Rectangle *rectangle, int y) {
rectangle->base.y;
}

change to

void rectangleSetY(Rectangle *rectangle, int y) {
rectangle->base.y = y;
}

Note from the Author or Editor:
Page 197
First code segment
Second function

Change:


void rectangleSetY(Rectangle *rectangle, int y) {
rectangle->base.y;
}

To:

void rectangleSetY(Rectangle *rectangle, int y) {
rectangle->base.y = y;
}