Book Description
Software failure in high-profile areas, such as aerospace, defence and medicine frequently makes the headlines because of the potentially disastrous consequences. The huge and recent growth in the use of software development has particularly serious implications for such safety-critical and high-integrity systems.
Despite its popularity and the excellent tool support available, C is only suitable for use in these areas within firm constraints and guidelines. Safer C: Developing Software for High-integrity and Safety-critical Systems highlights the 'holes' in C, but also demonstrates clearly that, employed correctly, C can be used to write software of as high intrinsic quality as other languages.
Beginning with a broad overview of safety in software, the book provides a critique of C as a safety-critical language, based on the author's extensive measurements of commercial C quality. Complexity, safer subsets, standards and tools are all examined. Essential rules of good working practice and guidelines for immediate implementation are presented and a direct comparison is made of specific safety-related features in C and other commonly-used languages. This important and timely book contains vital information for all developers working with C, whether in high-integrity areas or not, who need to produce reliable and effective software.
Special features include: much needed guidance for all software developers using C, not just those working on high-integrity and safety-critical systems; practical points for immediate implementation based on the use of safer subsets; and an examination of poorly understood legal implications of software safety and references to standards throughout.
Many moons ago, when I was a C developer, I stumbled upon Les Hatton and Safer C. It was an eye opener about the language I thought I knew. That's when I learned that the implementations of language standards may not be compatible with each other. And that, both for C and C++, one needs to define a subset of the language for their team to be able to have a consistent code base.
As I said, that was a long time ago. Now, I use mostly C# on a daily basis and it's comforting that that kind of problems are mostly non-existent in C#. But, then again, language standards for C and C++ kept evolving and maybe they could also address those issues over the years. I hope this old book (1995) is no longer necessary.
They didn't
It is
What about the new standards like C17? I understand that it's not easy to fix incompatibilities between vendors, but I would expect some of the "bug"s to be fixed?