Errata

"As of this writing, most compilers support C99 plus or minus a few caveats; the
long double type seems to cause a lot of trouble, for example."

The long double type is not a new feature in C99. It was introduced by the 1989 ANSI C standard, if not earlier.

The only implementation I know of that has trouble with long double is MinGW, because it combines the gcc compiler with the Microsoft runtime library. Both handle long double consistently, but they give it different sizes, making the combination inconsistent.

Note from the Author or Editor:
This should've read "long long double". Fixed by BK in commit 98f8f38.

To delete the side branch one doesn't use "git delete other_branch", but "git branch -d other_branch" or it's stronger version "git branch -D other_branch" ("git branch -d --force other_branch" in latest git version) if the other_branch was not merged into current one.

There is no "git delete" command.

Note from the Author or Editor:
That was silly of me.

Fixed by BK in commit 589f34b.

Changed "git delete" to "git branch -d". The discussion is about what to do after merging, and git gives increasingly friendly advice about when "git branch -D" is necessary, so I don't think it necessary to add to the text.

"The standard distance is the $L_2$ norm, aka Euclidian distance,
meaning that the distance between $(x_1, y_1)$ and $(x_2, y_2)$ is
$\sqrt{(x_1-x_2)^2+(y_1-y_2)^2}$. This is $L_3$,
$\sqrt[3]{(x_1-x_2)^3+(y_1-y_2)^3}$."

The definition of $L_3$ norm in two dimensions lacks absolute value sign, namely to be a norm the equation for it needs to take absolute value of difference between components, namely

$\sqrt[3]{|x_1-x_2|^3 + |y_1-y_2|^3}$

This does not matter for $L_2$ (Euclidian) distance because (x_1-x_2)^2 is positive, and symmetrical change 1 <-> 2. This doesn't matter for code, because it uses Apophenia
library: apop_vector_distance(g->position, position, .metric='L', .norm=3).

Note from the Author or Editor:
Good catch!

Fixed by BK in version 73219f0.

In example 12-6 we are importing "openmp_getmax.c" from example 12-5 with the intent of using the function defined in "openmp_getmax.c" called `get_max()`. However, in code listing 12-6, `get_max_factors()` is used instead. I think in Example 12-6 we should be calling `get_max()` instead of `get_max_factors()`.

Note from the Author or Editor:
This is correct---in fact, get_max_factors doesn't even exist in that code segment. The sample code gets this right---otherwise it wouldn't compile.

Fixed by BK in text revision aa04a3c.

In the bullet, the text states: " If you are using GNU Make, you have the option of capitalizing the name to Makefile if you feel that doing so will help it to stand out from the other files."

BSD make, Solaris make, and GNU make all have search orders. All three will use a lower-case named makefile before using the upper-case version (in the absence of a '-f' filename).

We used to always use an upper-case named Makefile. That way, if a developer needed to run a couple of experiments, they could just copy the Makefile to makefile, make a few changes, try it out, and then delete it.

This is guaranteed behavior stated in the man page.

Note from the Author or Editor:
Now that you point it out, I re-checked, and capital-M Makefile is fully POSIX-standard. Thanks.

Fixed by the author in revision 3e62046.

is command line:
./configure --host=ming32

should be:
./configure --host=mingw32

Note from the Author or Editor:
Fixed by BK in commit fba5fc9

in the section where he talk about makefile variables or command line variables , the part where he said:

" All of these means are equivalent, as far as your makefile is concerned, with the exception that child programs called by make will know new environment variables but won’t know any makefile variables. "

i think this is not right , the command line makefile variables will be visible to any child programs called by make as any new environment variables , let take an example:

if i call make from the command line like this:

make CFLAGS="-g -Wall"

and inside the makefile :

$(P):
echo $(CFLAGS)

the result will be displaying "-g -Wall" on the screen .

so the value of CFLAGS is visible to echo even it's set on the command line when calling make which make it makefile variable and here echo will be the child program .

so i think that this exception is wrong .

Note from the Author or Editor:
You make a good point. Checking the POSIX standard now, it says that "Before the makefile(s) are read, all of the make utility command line macro definitions (except the MAKEFLAGS macro or the SHELL macro) shall be added to the environment of make."

Thank you for pointing out this exception.

----
Fixed by BK in revision 33cab4e.

The description of $< is incorrect.

$< is the first prerequisite for the rule in question. It doesn't matter if that file has been modified or not.

$? on the other hand are *ALL* the prerequisites that are newer than the target.

See e.g. https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html

This should demonstrate the difference:
$ cat makefile
foo: bar baz qux
@echo First prerequisite: $<
@echo Newer than target: $?
@touch $@
$ touch bar baz qux
$ make
First prerequisite: bar
Newer than target: bar baz qux
("foo" is now up to date, but touch one or more of the files and the rule has to be executed again.)
$ touch qux
$ make
First prerequisite: bar
Newer than target: qux

Note from the Author or Editor:
Interestingly enough, GNU make and the POSIX spec differ here. My text is a paraphrase of POSIX [ http://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html ]:
"In an inference rule, the $< macro shall evaluate to the filename whose existence allowed the inference rule to be chosen for the target."

The commenter is correct that GNU Make treats $< differently. From its manual: "The $< variable evaluates to the first prerequisite in the first rule for this target."

Version 7c47753 puts the GNU Make definition in the text and the POSIX definition in a footnote (because I've asked around and can't find anybody using a non-GNU version of make).

You forgot to mention the "-c" option, without which cc/c99/gcc will try to make an executable, not an object file.

Luckily, make doesn't forget to add the "-c" option, if you ask it to build an .o file:

$ cat makefile
P=program_name
OBJECTS=
CFLAGS = -g -Wall -O3
LDLIBS=
CC=c99

$(P): $(OBJECTS)

$ touch program_name.c
$ make -n program_name.o
c99 -g -Wall -O3 -c -o program_name.o program_name.c

Note from the Author or Editor:
Thanks for catching this.

Version cd4346b replaces the erroneous recipe with the POSIX recipe,
$(CC) $(CFLAGS) -c $<
and fixed the verbiage accordingly.

I was not able to compile the code in dynamic.c. This was due to the use of the strcmp() used on line 20 and <string.h> not being included in the header.

Note from the Author or Editor:
Good catch: readline.h includes the strcmp declaration somewhere in there, but it should be explicit. fixed in book repository commit c0879ed and example repository commit c651032.

** ignore my previous errata, which contained an error **

"Python generally copies scalars but aliases lists (unless you use copy or deepcopy."

This is a bit pedantic, but strictly speaking Python aliases scalars:

i = 1
j = i
assert i is j

It's true that incrementing i won't affect the value of j, so that they behave as if j were a copy, but that's because scalars are immutable, meaning that the increment operation changes where the reference points rather than changing the value of the referenced object:

old_id = id(i)
i += 1
assert i == 2
assert j == 1
assert id(i) != old_id
assert id(j) == old_id

Note from the Author or Editor:
BK added a (hopefully) clarifying footnote in commit 2427e7d.

The sections weighing pros/cons of enums vs strings mistakenly assume that 8-bit instructions would execute faster than 16-bit instructions. While a narrower bit width could in theory be executed faster, in practice modern computer architectures tend to schedule instructions under a uniform clock rate.

So manipulating a 1, 2, 4, 8, 16, 32, or 64 bit structure on modern computers will all use the same clock time. This happens even with variable length instructions: Chip makers have learned to convert Intel code to RISC-like implementations behind the scenes.

On the other hand, it is true that fewer bits save more space, and load time may be significant in the context of arrays of 8-bit vs 16-bit numbers. But in general, enums are considered an extremely efficient and safe tool for modelling categorical things.

Note from the Author or Editor:
Yes, it was an overstatement to claim that an 8-bit comparison is always faster than a 16-bit, and reworded the sentence accordingly: "So even if the speed argument were relevant, comparing chars would be as fast or faster than comparing enums."

But I am leaving this sentence in place, because some of the books this chapter is responding to do push the efficiency of enums as a selling point for their use (sorry, no time to pull up references right now). I felt a sentence responding to this literature was worth including.

Fixed in revision f845bd6.

The line

“Recall that 8 bytes is not nearly enough to express all characters in one unit, so a single character is between one and six units long.”

should probably read

“Recall that 8 bits is not nearly enough to express all characters in one unit, so a single character is between one and six units long.”

Note from the Author or Editor:
Yes, good catch.

Fixed by BK in commit fdabfbf.

"Some things are surprisingly easy thanks to the array nature of strings. Given
char* str="Hello";
you can turn a Hello into Hell by inserting a NUL character:
str[4]='\0';"

This is violation of 6.4.5/7 subclause (String literals) according to C11 Standard (referring to N1570 draft) as well as by previous C99 and C89 Standards. The result is undefined behaviour:

"If the program attempts to modify such an array, the behavior is
undefined."

The valid way would be to replace string literal with string array like:

char str[]="Hello"; // the number of elements is guessed by initializer.

Note from the Author or Editor:
Good point. Fixed by BK in repository, commit 4950db5.

in the paragraph:

You saw another example several times above: in the evaluation of
printf("hello\n"), the expression is replaced by a zero on success, but the evalua‐
tion is useful for the side effect of changing the state of the screen.

the part when he said:

the expression is replaced by a zero on success,

i think that expression printf("hello\n") will be replaced by the number 6 not zero because printf On success it will return the total number of characters not just zero.

Note from the Author or Editor:
Good catch. Fixed in revision dcdaffe.