When It Comes To Programming In C, It's Better To Be Safe Than Sorry

It doesn't take too many programming classes for budding would-be engineers to realize that within almost any program, anything and everything that they think might go wrong, can and will do so. Once confronted with the quirks of real-world applications, few engineers would foolishly argue that their programs are absolutely bug free, able to execute all program threads without variation or loss of control.

But for embedded systems programming, the public de-mands a higher level of reliability. The more critical the system, the greater an emphasis we must place on proving that nobody's life will end due to a programming error. After all, it's pretty clear what the implications are if the air bag doesn't release on impact or if the MRI scan misses a tumor before it becomes too intrusive.

With embedded systems, it's also important to provide the most cost-effective solution. In many applications, this means using C, the de facto standard for higher-level language programming. C offers inherent language flexibility, strong support, and the potential for portability across a wide range of hardware.

Yet C has many areas of concern that potentially jeopardize the high level of integrity required from final executable code, especially for mission-critical applications. If your number one concern is to protect human life, then something must be done to ensure that C delivers that higher level of assurance and security.

With this in mind, the Motor Industry Software Reliability Association (MISRA, www.misra.org.uk), a consortium of automotive companies and institutions, published "Development Guidelines for Vehicle-Based Software" in 1994. It describes software-development requirements, specifically the choice of languages, compiler, and language features for use in relationship to integrity level. In 1998, the consortium developed guidelines specifically for promoting the safest possible use of C in automotive applications (see "Guidelines for the Use of the C Language In Vehicle-Based Software" on MISRA's site).

These guidelines identify aspects of C that should be avoided in safety-related systems, along with other recommendations about using other C features. The C guidelines contain 127 rules related to using the ISO/ANSI standard language for C together with justifications and examples.

Recognizing the advantages of MISRA's C guidelines, Tasking immediately implemented the Safer C concept in its software development environment. The Safer C concept can be viewed at www.tasking.com/products/TriCore/saferc.pdf/.

By defining selectable C-usage restriction rules, Safer C guides programmers in writing more coherent, robust C code. Through a system of strict error checking, the use of error-prone C constructs can be prevented. To ensure compliance with Safer C rules throughout the project, Tasking set its linker/locator to generate a Safer C Quality Assurance Report that lists the different modules in the project with the respective Safer C configurations used to compile them.

Should such subsets of C be created? Some purists would say, "No, what's good for one is good for all." I contend that C provides a universal standard that's easy to use and comprehensive with minimal overhead. This common denominator ensures that the C language suits typical application requirements, keeping development costs down for the vast majority of users.

Introduce the mission-critical error checking of Safer C, and what do you have? A compiler that ensures safe programming constructs are in place. Yes, there's additional overhead and checking, but it's a small price to pay for preventing the potential loss of human life.