Why you need the C Standard
The wind was howling, the rain torrential. I estimated peaks of 80 knots. Storms, even short summer thunderstorms, are always fun, and we were watching the trees wave from a window overlooking the back yard. When the rain let up I changed windows to get a different perspective. A smile formed; I called Marybeth over and pointed to the neighbor’s tree that had fallen onto the barn, crushing the structure. Since moving here five years ago we had a long-term plan to replace the building, its dirt floor and leaky steel siding not really what we wanted. The insurance settlement wasn’t enough for a new barn, but will make a big dent in the costs.
We talked through our ideas about the new building, scribbled some crude drawings to get a sense of what would work, and then did not break out the drawing board.
Instead, I bought a copy of the International Residential Code.
The IRC is a mind-numbingly-dull 900 pages of rules and regulations about every aspect of residential design. Many rail against what is perceived as communitarian prescriptions that at times make little sense, or that are just so completely anal one wonders what the committees were smoking. But tilting at windmills is hardly productive, and the inspectors will certainly fail our work if we try to circumvent the IRC’s rules.
The code is the basis of the design of all residential buildings.
Analogously, the C standard is the basis of the design of most of our work. The C11 standard is over 700 pages. It’s practically unreadable; is more potent than Lunesta, and seems more useful as a door stop than as an engineering document. It is one of the driest and most boring books ever to hit the street, so it's unsurprising so few of us have read it, or even flipped through the pages.
But it is full of gems that the more accessible C books seem to miss.
I have written about the assert() macro on occasion. In my opinion it is one of the most powerful debugging aids the language provides, yet a grep of 30 million lines of embedded code here produced not a single hit for that macro. I often talk to firmware developers who are only vaguely aware of it. Most of my C books don’t mention it. Even K&R’s second edition ignores it other than a brief, 10 line mention, in a dry appendix. The C11 standard devotes a full page to assert() and show it used in examples in other locations.
Appendix F is a must-read for all developers. It’s hard to get floating point math right. I see so much code where the developer painfully developed rounding and other functions, yet this appendix details functions that C provides to handle this operation. Are you familiar with isfinite()? Have you ever read a C book that talks about it? Did you know that using the comparison operators on floating point numbers may be dangerous since they don’t account for NaN? More robust comparisons are provided by the standard.
Appendix C lists sequence points, whose meaning is outlined in the chapter titled “Environment,” which are a critical concept for understanding how the compiler can re-order execution. Compilers can do crazy sorts of optimizations, but sequence points bound their zaniness.
The C11 standard is available here for 198 Swiss Francs, or about $210, an outrageous price for a .PDF. Various web sites make it available, at least in pre-final versions, but I have no idea about the legality of that practice. The C99 standard, more common in the embedded world, is also available.
As professionals, we all owe it to ourselves, and to our careers, to have easy access to the foundational documents of our industry. And we need to read them! Only a masochist would sit down and plow through an entire standard. Instead, like enjoying a fine wine, sip at it from time to time (perhaps with a nice adult beverage at hand).
Dry? Yes. But some sections are quite interesting and worthwhile. College classes on electromagnetics and circuit theory were also dry, but ours is a very technical profession and we simply must master the material.
Do you have a copy of a C standard?
Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges, and works as an expert witness on embedded issues. Contact him at firstname.lastname@example.org. His website is www.ganssle.com.