IAR’s MISRA C support provides fine-grain selection of rules to be checked.
One of the best ways for programmers to shoot themselves in the foot is to program in C. Of course, C and C++ dominate embedded programming, so reducing the potential for an injured limb tends to be helpful.
Embedded C Coding Standard, a short book by Michael Barr of Netrino, is a good starting point. So are the C and C++ standards from the Motor Industry Software Reliability Association (MISRA). MISRA C started in the U.K. automotive industry, but since then it has been utilized in a range of embedded tools like the C and C++ compilers found in the IAR Embedded Workbench.
I recently had a chance to try out IAR’s tools to exercise the MISRA support. It allows fine-grain control over the more than 100 rules in MISRA C (see the figure). Selective control is key as MISRA C, or its variants, may be a requirement in all settings, and not all of its rules may be desirable.
Restricting Programmers
MISRA C Rule 1—all code shall conform to the ISO 9899 standard, with no extensions permitted—prevents 100% implementation on 8- and some 16-bit platforms where extensions are needed to access some hardware features like index or page registers.
Some rules like Rule 118—dynamic heap memory allocation shall not be used—are completely impractical for many dynamic environments. On the other hand, statically defined structures provide well known limits on system capabilities and are perfectly adequate for applications like motor control. Also, I liked many of the pointer and array rules. For example, pointer type casting and pointer arithmetic are not allowed.
Now we know why pointers were key to C in the beginning. Efficiency was important because coding could match instruction implementation like autoincrement instructions, and the original C compilers were not great at optimization.
Today’s compilers will do a better job at optimization than any programmer in general and better than most all the time. For example, code for loops indexing an array will often utilize autoincrement instructions if the target hardware supports them. This makes the source code more portable and less prone to errors.
Not all of MISRA’s rules can be checked via static analysis. Some require code reviews and tend to be general recommendations for coding practices.
MISRA C Alternatives
MISRA C support can be found in a number of commercial compilers like IAR’s and those from Green Hills Software, Altium, and Hitex. Tool vendors like Coverity, Grammatech, Klockworks, and LDRA that provide static analysis tools for C and C++ that are even more sophisticated than the restrictions set by MISRA C (see “The Latest Static And Dynamic Analysis Tools” at electronicdesign.com). MISRA C support is just one of many options with these tools.
The overhead for checking MISRA C-style rules is relatively low, but the static analysis tools from these vendors do significantly more. The rules attempt to reduce errors through good programming practices. These tools actually detect errors, not just rule violations.
The flow analysis can detect problems such as unreachable code. Some tools can even detect when file operations would occur before a file is opened. Some compilers like those from Green Hills Software incorporate some of this type of static analysis.
Some developers will note that the GNU gcc compiler offers a host of flags that provide many checks like those found in MISRA C. That is true, and they may be sufficient. However, they come in a poor second to more advanced analysis tools. This makes sense because the compiler typically needs to create the same kind of internal representation of the program that the static analysis tools do.
An interesting prospect for integrated static analysis tools is the LLVM (Low Level Virtual Machine) toolchain. LLVM uses front ends to handle specific languages like C and C++. One project called Clang Static Analyzer provides functionality similar to that found in some standalone commercial products.
Even the original Lint program was more flexible. Splint, or Secure Programming Lint, is very extensible (see “Static Source Code Analysis” at electronicdesign.com). Gimpel Software’s PC-Lint is another alternative.
So what kind of tools are you using to improve the safety and reliablity of your C and C++ code?
GimpeL Software
www.gimpel.com
Green Hills Software
www.ghs.com
IAR
www.IAR.com
MISRA
www.misra.org.uk
Netrino
www.netrino.com
