Search in Book Reviews

There is another review of this book, written by Derek M Jones, in the May 2009 CVu. If you consider to buy or read this book, please read that review first. Derek classified the book as 'not recommended' with fair explanation. And the facts he list are true.

Yet, the interpretation of the facts can be different. The book is on a very serious topic – problems that cause software problems, especially "security vulnerabilities", that manifest in the world in spreading malware, data loss, data theft, with the monetary impact measured in $ billions yearly. The rules and guidelines in the book, if put to life could decrease these kind of defects much. While indeed many guidelines can be called 'platitudes', still they are not followed, and in 2009 the software is still full of those banal problems. Among them those pesky format strings still create 'hack-me' engines, despite the many texts about them and specific warning built in the compiler...

This book is not very good for you, if:

• You are on starter level, or did not read some other morality guides and guideline books. You need a fair amount of background, or follow all the listed references.
• You work on a system is not (mostly) C99. If your system is C++, many of the listed problems apply, but the solutions are very different. Wait for the C++ version, that is under work; you can use the material on the web. If your system is C90, you’ll need adjustments (or follow the suggestion to go C99).
• You’re short on budget. The material is on the web for free access, you can buy books not available.

This book is good for you, if you have a C project with problems, and you're responsible to make it better. Especially if you have to create or manage the guidelines, the process, allocate resources. It can save you very much time, providing much preprocessed material., both the content and ideas of sections, applications. I very much liked the idea, that every item has an ID, and the exceptions too. When put to work, it can streamline reviews and corrections, just using those. Also the calculating of ‘priority’ and ‘level’ that includes the estimated cost of cleanup.

For each item there is also a good list of references, covering both theory and the actual vulnerabilities encountered in the world.

Derek felt the severity and impact values are too subjective. As I see this is not subjectumive, but the source of the book – it was created mostly from 'security vulnerabilities' observed. That is certainly a subset of all possible problems. And someeach real system has its own environment.

If the guidelines are put to use, that should not be a problem, as the adopter can substitute the relevant values, along with selecting items from here, and elsewhere.

The book is also a good read for seniors who know most of the problems, but can find a couple they were no aware of yet. And possibly find some manifestations in the codebase. You can do it on the web too. That is well maintained, so if you spot a problem, just leave a comment, it may trigger update overnight.

So as summary this book is not perfect, is not a silver bullet, also will not replace knowledge and thinking of good engineers – but can be used for good is one wishes, and nets a fair value.