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.

Sponsored Recommendations

Understanding Thermal Challenges in EV Charging Applications

March 28, 2024
As EVs emerge as the dominant mode of transportation, factors such as battery range and quicker charging rates will play pivotal roles in the global economy.

Board-Mount DC/DC Converters in Medical Applications

March 27, 2024
AC/DC or board-mount DC/DC converters provide power for medical devices. This article explains why isolation might be needed and which safety standards apply.

Use Rugged Multiband Antennas to Solve the Mobile Connectivity Challenge

March 27, 2024
Selecting and using antennas for mobile applications requires attention to electrical, mechanical, and environmental characteristics: TE modules can help.

Out-of-the-box Cellular and Wi-Fi connectivity with AWS IoT ExpressLink

March 27, 2024
This demo shows how to enroll LTE-M and Wi-Fi evaluation boards with AWS IoT Core, set up a Connected Health Solution as well as AWS AT commands and AWS IoT ExpressLink security...

Comments

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