Expert C Programming: Deep C Secrets by Peter van der Linden

How did I miss this book?

That's a rhetorical question. I know how I missed it. It came out in the early to mid '90s, amidst a flock of other books with titles including "expert", "deep", and "secrets". All of those other books were crap. So I remember seeing it and thinking, "Expert? Secrets? Yeah, right."

It turns out, I shouldn't have done that.

Peter van der Linden wrote a very good book about the parts of the C ecosystem that are very, very important, if you need to do something more than a quick tutorial about C programming. That includes:

• A history of C (quite a few of C's quirks are path-dependent, history-wise), including a discussion of the standards committee's use of undefined, unspecified, and have-you-lost-your-mind when describing the proper behavior of a C compiler. van der Linden gives a good description of some of the more common of the traps laid for the unwary in the name of supporting some other architecture that you've never heard of and bringing more faster performance to your crappy code with no effort from you, although he wasn't as aggressive about it as some modern C authors would like, I suppose. On the other hand, the book was published in 1994, and the standards committe has ensured that the dark, weird places in C have gotten darker, weirder, bigger, and more numerous in the decades since.

• What's up with C declarations. Yeah, I see what you're trying to do there, guys, but I still a bit foggy on why you want to do it.

• How, exactly, arrays are not pointers, how they sort of decay into pointers under some (well, most) circumstances, and why those of us who have been using C for decades no longer think that's odd.

• A short introduction to how a C compiler works (for most values of "a C complier), including why the phases of compilation are numbered p, 0, c, 2, a, and 1. (Actually, I mean l on that last one. Fonts are hard.) This includes a discussion of the most ignored part of compilation, linking. At least, enough to give you a running start when the link phase starts blowing chunks all over your desk.

• Another short introduction to the C runtime model. Most languages would consider that reasonably covered by the basic semantics of the language, but with C, you are up to your elbows in the guts of the machine, and because you are writing code that is actually fairly portable, you may not know what color those guts are when you're writing the code. Plus, leaking memory for fun and profit.

Now, I do have to say that I'm familiar with most of this stuff. I should be; C is my native language. Or, at least, I was familiar with it at some point in the past. These days, I feel lucky to be familiar with the bottom of my cereal bowl. But if I wasn't, Expert C Programming would be a delightful introduction to them. It's well written, with an excellent sense of humor. (Editor's note: that might be humor, and it might be the strange, cackling insanity that comes from knowing too much about C. It is difficult to say. Either way, it's all good.) As it is, I have found the book to be a very engaging read.

To conclude, here is an example:

Another problem [with linking] occurs if you mention the static libraries before your own code. There won't be any undefined symbols yet, so nothing will be extracted [no code from the library will be included in your program]. Then, when your object file is processed by the linker, all its library references will be unfulfilled! Although the convention hass been the same since UNIX started, many people find it unexpected; very few commands demand their arguments in a particular order, and those that do usually complain about it directly if you get it wrong. All novices have trouble with this aspect of linking until the concept is explained. Then they just have trouble with the concept itself.

One final advantage: the book has a coelacanth on the cover.