Safer C (McGraw-Hill International Series in Software Engineering) [Paperback]

Les Hatton (Author)

Book Description

ISBN-10: 0077076400 | ISBN-13: 978-0077076405 | Publication Date: 1995

This book is aimed at C developers in safety-related or high-integrity environments.

Product Details

• Paperback: 228 pages
• Publisher: McGraw-Hill Companies (1995)
• Language: English
• ISBN-10: 0077076400
• ISBN-13: 978-0077076405
• Product Dimensions: 9.7 x 6.8 x 0.6 inches
• Shipping Weight: 1 pounds
• Average Customer Review: 3.0 out of 5 stars  See all reviews (2 customer reviews)
• Amazon Best Sellers Rank: #1,577,720 in Books (See Top 100 in Books)

More About the Author

Discover books, learn about writers, read author blogs, and more.

Customer Reviews

Most Helpful Customer Reviews

18 of 19 people found the following review helpful:

3.0 out of 5 stars A good addenda to Kernighan & Ritchie, August 21, 1999

By 

Erick M. Griffin - See all my reviews

This review is from: Safer C (McGraw-Hill International Series in Software Engineering) (Paperback)

Well when first introduced to this book the title evoked some interest in me, my development background being in C/C++. And though my first impressions remained hopeful, it soon became clear that this book has a very defined audience indeed.

I must admit I find much of what Les Hatton says about the C language and its application in high integrity very interesting but perhaps its relevancy today isn't what it once was. Don't get me wrong, there is some good information in this book and you may even have an epiphany about the C language while you read it. But Les's lack of lucidity makes the book very dry to read, and unless you are an avid fan of standards and rigid processes or can find some humor in what he says, you might find getting through any of the chapters somewhat of a challenge.

Moreover the reader is constantly and implicitly reminded while reading this book of the author's staunch support for the C language. And though this takes many different forms throughout the book, it became clear to me at least, that here may be a case where someone has gone through a great deal of work in the defense of a programming language instead of propounding the use of a more appropriate one. That is not to say there may not be situations where the C language is necessary in mission critical or high integrity software; I just don't think the author has given ample justification in these cases for considering other more strongly typed languages than C for them.

However, there are some sections and chapters of the book that are worth some note. I found the following of interest because of it potential applicability to what all software engineers need to be aware of, particularly in Tivoli.

Chapter 2. This entire chapter is useful to those individuals who really want to teflon coat their C code. The author skillfully wades through all the potentially caveats and misbehaviors that can haunt someone writing in this language. Along with his obvious vast experience with standards it becomes painfully clear that he has fallen victim to some of them.

Sections 5.1.2 and 5.3. The former section has a good synopsis on test coverage and for those who do any development or testing with C may find what he has to say here of some use. The latter section contains some good information on automation and tools, and though you will definitely find yourself skipping through it (especially the parts on standards and ISO), much of what he has to say has some value to what we do in Tivoli.

This book does not belong on everyone's shelves and is clearly not meant for the novice or uninitiated programmer or engineer. It is useful however in those handful of cases where one absolutely needs to understand what the limits of C are, and then to take the necessary design, development or verification action to meet those potential challenges. I find it a useful though a decidedly optional appendix to any Kernighan and Ritchie...

14 of 16 people found the following review helpful:

3.0 out of 5 stars Original ideas on developing engineering practices, August 17, 1999

By 

Bret Pettichord (Austin, Texas) - See all my reviews
(REAL NAME)   

This review is from: Safer C (McGraw-Hill International Series in Software Engineering) (Paperback)

This book was recommended to me by a collegue. Looking at the title, I don't think I would have picked it up myself. My interests tend towards the practical. But this was a surprising delight to read. Hatton is sharp, well-informed and very funny. And I was surprised at how similar the challenges that Hatton addresses are to the ones faced by the development groups I've worked with.

Hatton's primary motivation is to defend C as a language for use in safety critical systems. And that's an argument that I don't have much interest in. But he defends it by identifying unreliable features and usages of C and showing how these can be automatically detected and avoided. This is the interesting part. His analysis is deep and entertaining. He obviously has spent many many hours reading draft standards and commentary. The task has nearly turned his brain to jelly. Yet he pressed on and has identified and categorized long lists of issues that the standards leave open to interpretation.

The second basis for his argument are empirical studies he has made of occurances of faults in software. These are also very interesting. He also has made studies correllating complexity metrics to these fault metrics and thereby comes to well-defined complexity criteria. But having defined some metrics, he also has good ideas about how to make use of them.

Hatton doesn't have much faith in process standards (such as the CMM, or ISO 9000). He feels that if you have to have rules, they need to have automated enforcement mechanisms. Indeed, one of the purposes of this book is to plug tools that do just this that he has developed. But he also describes competing and complementing tools with fairness. Indeed, his descriptions of the different static and dynamic code analysis tools is the best one I've seen. I learned several useful things from this section alone. He also realizes that you can't have arbitrary limits. So he often suggests that a grey zone be defined where formal written justifications can allow code to exceed the lower limits. It is clear to me that if we are going to continue to call ourselves software engineers, we will need to be spending more time defining, following and justifying the engineering practices we use. Hatton's analysis is a useful model, because it shows how this can be done without hopping on to one of the latest management buzzword models.

His background as a geologist shapes his expectations for computer languages and software. He doesn't have much sympathy for ambiguous specifications and standards. He expects a lot, but he also knows that we have the knowledge and ability to meet these expectations -- expectations that anyone else who wants to be called an engineer accepts.