ACCU Home page ACCU Conference Page
Search Contact us ACCU at Flickr ACCU at GitHib ACCU at Google+ ACCU at Facebook ACCU at Linked-in ACCU at Twitter Skip Navigation

Search in Book Reviews

The ACCU passes on review copies of computer books to its members for them to review. The result is a large, high quality collection of book reviews by programmers, for programmers. Currently there are 1918 reviews in the database and more every month.
Search is a simple string search in either book title or book author. The full text search is a search of the text of the review.
    View all alphabetically
The Cert C Secure Coding Standard
Robert C Seacord
Addison Wesley
Derek M Jones
C, secure code
Appeared in:

This book follows in a long tradition of providing recommendations to users of a programming language on how to write more reliable software. While the title and contents use the word security many of the recommendations have the more general audience of developers interested in writing reliable software.

The 14 chapters are divided by language and library topic (e.g., preprocessor, floating-point, memory management, signals) and each chapter contains around 10-20 or so recommendations on that topic. Recommendations follow the same format, containing one or more of the following subsections: general discussion, noncompliant code example, compliant solution, exceptions, risk assessment and references. The 612 pages include an extensive index and code examples are the minimum needed to illustrate an issue.

The material assumes that readers have a lot of background knowledge. Each recommendation jumps right in and talks about very specific technical issues often with no background explanation. While some recommendations are labeled as being Microsoft Windows specific most of the material is OS agnostic, although it does make assumptions that best fit a desktop environment (e.g., the int type is 32-bits).

The recommendations could be grouped by where they came from. Many recommend against using constructs or relying on behavior that the C Standard specifies as being undefined, implementation defined or unspecified, others recommend doing things that could be categorized as 'good' coding practices aimed at avoiding a source of commonly encountered programmer mistakes (e.g., "Do not reuse variable names in subscopes" and "Do not use floating-point variables as loop counters"), while others are platitudes (e.g., "Understand how arrays work" and "Take care when creating format strings").

I have been in the source code analysis business, mostly involving C, for almost 20 years and in many places I found I had to read the material several times to understand the point that was being made. The discussion often has little narrative thread, jumping around between topics and introducing topics unrelated to the issue at hand. The wording of some recommendations bears little resemblance to the actual coding issue, e.g., "Do not apply operators expecting one type to data of an incompatible type" is the recommendation wording used to describe the problems that occur when a pointer is assigned the address of an object having an incompatible type and that pointer is then dereferenced to obtain a value.

Platitudes can be ignored, but every time I encountered one, I stopped counting at 20, my opinion of the recommendations dropped. But overly generalised recommendations will result in an unnecessary increase in costs if followed, e.g., the recommendation "Do not simultaneously open the same file multiple times" does not apply if all of the files simultaneously open are for reading.

While it contains lots of recommendations it still manages to miss some of the more commonly encountered ones, not comparing floating point values for equality being the most obvious omission.

The 'Risk Assessment' subsection is a good idea that seems to have been poorly implemented. No information is given on how the likelihood of a recommendation not being followed and the severity of the consequences was calculated; values appear to have been pulled out of the air. From my own measurements of source code I know that some of the likelihoods are incorrect. Severity is very hard to judge, an uninitialise variable may result in a coffee machine occasionally failing to add/omit sugar or firing a missile attached to an aircraft still in its hanger (I know of a case where this happened).

This book is the paper edition of the information available on the web site. I have bought paper versions of books whose pdfs are freely available on the web. Is it worth paying £38.99 for a paper copy of this web site (which is actively updated)? Unless the paper version contains lots of color diagrams 611 pages for £38.99 is a poor deal.

This book contains a significant amount of material that still needs lots of work to make it understandable to the non-expert programmer and to fix the numerous small technical errors.

This book should really have been written to accompany the web site, providing background information and an overview of each of the major topics. As a paper version of the web site it is poor value for money and for material that still needs lots of work.

Not recommended.