MISRA C: Safer Is Better

Feb. 3, 2003
Vehicle software design outside the entertainment realm is tougher than most system designs. Reliability and safety usually hold greater significance than features or maximum performance. On the whole, hardware and software designs tend to be very...

Vehicle software design outside the entertainment realm is tougher than most system designs. Reliability and safety usually hold greater significance than features or maximum performance. On the whole, hardware and software designs tend to be very conservative.

The C programming language is very popular for vehicle platforms. Unfortunately, creating bugs in C is notoriously easy. Dangling pointers, buffer overruns, and even a missing plus sign can wreak havoc on even the best system design. One way to minimize such errors is to reduce the power of C by restricting the features a programmer can use.

The Motor In-dustry Software Reliability Association (MISRA) takes this approach with its C guidelines. The MISRA "Development Guidelines for Vehicle Based Software" document contains 127 rules relating to the ISO/ANSI standard programming language for C, along with justifications and examples. A number of popular embedded C and C++ compiler vendors implement these rules so programmers can have abuses flagged as warnings or errors.

Although MISRA C, as it's called, is intended for the development of embedded automotive systems, it's equally applicable to almost any embedded application environment. Many of the MISRA C rules restrict the use of C features like pointers. Pointers are often used for efficiency purposes, even when alternatives such as array indexing can provide the same effect.

In the past, using pointers was explicitly more code-efficient and offered higher performance than arrays. Many current compilers internally transform array operations like these into pointer operations, essentially making the array-based source code into object code that's as efficient as the pointer version. The advantage is that the pointer-oriented compiler-generated code is created in a controlled fashion.

MISRA C's rules are divided into 17 sections, which include Declarations and Definitions, Control Flow, Pointers and Arrays, Structures and Unions, and Standard Libraries. Rules are additionally divided into required and advisory rules. Most C compilers implement MISRA C restrictions so that developers can employ the full standard or a subset of it. Selective use of MISRA C is handy when migrating an application to MISRA C.

Some may think that putting restrictions on programmers would result in mutiny, but most developers adept at using C will already implement many of the MISRA C rules informally. Rule 34 shown in the table is just one example. Embedded assignments are another. With over 120 rules, programmers will be hard-pressed not to find a few they prefer. Most are common-sense improvements that will appeal to programmers after they understand the rules and their implications.

MISRA C isn't a standard but more of a recommendation. The rules are written in plain English, although some rules are ambiguous, and some redundancy exists. There's no standard test suite, so MISRA C compilers or compliance testing tools can generate different error or warning messages for the same source code.

Not surprisingly, MISRA C is very popular in the automotive arena. MISRA C has also found a following in most embedded areas, simply because the recommendations are so complete. Any improvements through additional rules would be minor.

Programming experience is still important, even when using MISRA C. Although it won't completely eliminate bugs, MISRA C will help reduce the number of errors that find their way into an application.

www.misra.org.uk

MISRA C EXAMPLE
•Rule 34 (required)
•The operands of a logical && or || shall be primary expressions
   Invalid
   if ( x= = 0 && ishigh )
   Valid
   if ( ( x == 0 ) && ishigh )

Primary expressions are constants, a single identifier such as ishigh, or a parenthesized expression. Parentheses are important for readability and ensuring that the behavior is what the programmer intends.
About the Author

William G. Wong | Senior Content Director - Electronic Design and Microwaves & RF

I am Editor of Electronic Design focusing on embedded, software, and systems. As Senior Content Director, I also manage Microwaves & RF and I work with a great team of editors to provide engineers, programmers, developers and technical managers with interesting and useful articles and videos on a regular basis. Check out our free newsletters to see the latest content.

You can send press releases for new products for possible coverage on the website. I am also interested in receiving contributed articles for publishing on our website. Use our template and send to me along with a signed release form. 

Check out my blog, AltEmbedded on Electronic Design, as well as his latest articles on this site that are listed below. 

You can visit my social media via these links:

I earned a Bachelor of Electrical Engineering at the Georgia Institute of Technology and a Masters in Computer Science from Rutgers University. I still do a bit of programming using everything from C and C++ to Rust and Ada/SPARK. I do a bit of PHP programming for Drupal websites. I have posted a few Drupal modules.  

I still get a hand on software and electronic hardware. Some of this can be found on our Kit Close-Up video series. You can also see me on many of our TechXchange Talk videos. I am interested in a range of projects from robotics to artificial intelligence. 

Sponsored Recommendations

Comments

To join the conversation, and become an exclusive member of Electronic Design, create an account today!