MISRA C:2012 offers new opportunities for automotive systems developers

July 3, 2013  by  


Chris Tapp

Mark Pitchford

By Chris Tapp and Mark Pitchford, Field Applications Engineers at LDRA

The newest version of MISRA lets developers take advantage of more C features while helping them mitigate risk—and meet new standards requirements—for safety-critical automotive applications.

For C programmers working on automotive applications, following restrictions and guidelines to ensure safe-coding practices can be painful. Features of the language designed to make your work easier or more efficient, or to provide work-arounds for obstacles, are often just the features that the guidelines disallow.

However, quality concerns are driving the automotive industry to look seriously at ways to improve quality software development. Some of the key defects in automotive quality stem from the increased use of electronic systems that affect vehicle safety.

Automotive companies are looking to standards such as ISO 26262 to help them comply with the specific needs of the electrical, electronic and programmable electronic (E/E/PE) systems of road vehicles. And adherence to appropriate coding rules is one of the key demands of ISO 26262.

ISO 26262 is a relative newcomer as far as safety standards are concerned, although it shares a common ancestry with standards used in other safety-critical sectors (Figure 1). While it provides a sound framework in which to develop functionally safe automotive applications, it stops short of dictating exactly how that should be done.

Automotive developers often follow in-house templates, but with the increase in the amount of safety-critical electronics in today’s vehicles, combined with the increasing cost of litigation if software quality efforts cannot be proven, many of these developers are now looking at recognised outside guidelines.

Figure 1: Standards developed from the generic IEC 61508 standard

MISRA—a subset of the C language created in the 1990s by the Ford Motor Company and the Rover Group—has since become a coding foundation for many of these safety-critical standards.

Although ISO 26262 does not prescribe adoption of MISRA C, the updated guidelines provide a set of recognised best practices to help auto manufacturers mitigate risk in automotive electronics.

The latest version—MISRA C:2012—offers new opportunities for programmers by permitting more flexible use of the language while retaining the MISRA reputation as the safest C guideline available.

Spend more time coding, less time on compliance efforts

MISRA C was originally released in 1998 (MISRA C:1998) to target C90, and it was superseded in 2004 (MISRA C:2004) to include a host of extensions and improvements to the original.

The new MISRA C:2012 aims to make development as predictable as possible, across projects or pieces of code, without errors of interpretation. Repeatability and predictability are key drivers. Even a dispersed development team with multiple subcontractors that follows the MISRA guidelines can be confident that all of the code will be consistent across the project.

Following the new guidelines, whether classified as rules or directives, helps programmers mitigate software-related risks for safety-critical applications. Ultimately, it allows them to spend more time coding and less time on compliance efforts.

Reasons for a new MISRA version

Any updated coding practices or standards require developers to learn new guidelines and update their tools and programming methodologies. But this short-term inconvenience is outweighed by the advantages of updates that improve existing rules, extend support to the latest version of the language, and reduce development efforts overall.

MISRA C:2012 was designed to:

  • Extend the coding guidelines to embrace unsafe elements of C99 while retaining support for C90
  • Support and enhance the improved definition of undefined or unspecified behaviour in C99
  • Correct issues found in the 2004 version
  • Provide backwards compatibility as much as possible to make it unnecessary to modify code when moving from MISRA C:2004 to MISRA C:2012
  • Ensure all guidelines include a detailed rationale and remove rules without strong rationale
  • Increase the number of decidable rules to allow better tool enforcement and reduce the amount of manual checking, saving time and money
  • Include guidance on the applicability of guidelines to automatically generated code

 What does the new MISRA offer?

In MISRA C:2012, guidelines have been made more precise so that the standard will not prevent reasonable uses or behaviours that have no undesirable consequences. This will be good news for developers who may have been frustrated in the past by rules that were more restrictive than was necessary.

Instead of MISRA C:2004’s use of the term “rule”, MISRA C:2012 subdivides “guidelines” into “rules” and “directives” where a directive is a guideline for which it is not possible to provide the full description necessary to perform a check for compliance.

The new MISRA standard further defines rules as applying to a “system” or “single translation unit” analysis. And all guidelines now include detailed rationale, which should help developers understand the need for each of them, rather than leaving them to speculate on the rule’s intent.

The updated version also tells developers if a rule is “decidable”—those against which an analysis tool can always determine compliance or non-compliance—versus “undecidable”, where a person must make an assessment (generally due to pointer or data values affecting control flow) (Figure 2).

Undecidable rules can result in false-positive or false-negative test results simply because the tool has inadequate information available to it during analysis. This improvement in rules definition significantly reduces manual code-review requirements, and lets developers know ahead of time if another method of testing should be used.


Figure 2: Automated test tools can always identify “decidable” MISRA C:2012 rule violations. They provide hyperlinks to the offending code and to descriptions of the violations to help in their resolution. Such convenience complements the more user friendly nature of this latest MISRA standard.

MISRA C:2012 offers a reasoned approach

Let’s look at some specific examples of programming approaches that are now addressed with the more user-friendly MISRA C:2012.

Freeing memory: aka, being too clever for your own good

In some instances, developers have freed memory that is automatically allocated to variables for use elsewhere. This is legitimate C syntax, but is dangerous. The new MISRA rule prevents developers from being too clever for their own good. In this case, the rule states that a block of memory shall only be freed if it was allocated by means of a standard library function.

void fn ( void )


int32_t a;

free ( &a ); /* Non-compliant – a does not point to allocated storage */


MISRA C:2012 defines guidelines as “Required,” “Advisory” or as a new “Mandatory” category, and this memory rule, for instance, is an example of a Mandatory rule that must never be broken (Figure 3).

Required and Advisory guidelines can be broken with varying degrees of justification required, so that an “Advisory” rule might be at a programmer’s discretion, while “Required” might require the approval of a manager.


Figure 3: MISRA C:2012 introduces a “Mandatory” category for rules which must never be broken, to complement the existing “Required” and “Advisory” categories. As illustrated, automated compliance checking tools can summarise information on any identified violations.

The rationale behind the guidelines

The previous versions of MISRA dictated what should be done, offering no rationale to explain the rule’s intention. This new version enhances the concept of “rationale”, providing descriptions that explain why each guideline is a good idea.

For instance, it is now a requirement that typedefs that indicate size and signedness should be used in place of the basic numerical types. For example, on a 32-bit C90 implementation the following definitions might be suitable:

typedef signed char int8_t;

typedef signed short int16_t;

typedef signed int int32_t;

typedef signed long int64_t;

From the perspective of portability, the rationale debunks the possible false perception that adherence to this guideline guarantees portability because the size of the int type may determine whether or not an expression is subject to integral promotion. For example, an expression with type int16_t will not be promoted if int is implemented using 16 bits but will be promoted if int is implemented using 32 bits. In other words, the rationale helps guide the developer around a common pitfall.

Not all goto statements are evil!

All too often, goto statements are used to patch up fuzzy thinking or an ill-defined algorithm. Indeed, there are situations where the use of the goto statement is justified. For example, if there is an emergency situation in a guidance algorithm, it is better to take a direct route via a goto. There’s not time to set a flag and check its status later in the loop. Because of this, the “goto statement should not be used” rule is now advisory rather than required, and an additional two rules narrow down the circumstances under which it is acceptable:

  • The goto statement shall jump to a label declared later in the same function.
  • Any label referenced by a goto statement shall be declared in the same block, or in any block enclosing the goto statement.

Auto-generated code needs checking, too

Auto-generated code, often used for automotive applications, is still written by a software developer, whether as templates or hand-coded “S” models. Ensuring that the generated code complies with a language subset (such as MISRA AC) confirms that there are no errors in that manual implementation that affect the quality of the auto-generated source code.

The auto-generated rule set differs from that in hand-written C for a number of reasons. For example, auto-generated code can use variable names that are indistinguishable to human eyes but are still sufficiently unique for their purpose.

There are also occasions when auto-generated code is required to do the opposite of handwritten code. For instance, MISRA C rules dictate that a default statement should always be written into a case statement. The MISRA AC equivalent insists on the opposite because an auto code generator cannot decide what the default action should be; the necessary addition to implement the default has to be added manually. The MISRA language subsets offer a path for any developer to take full advantage of their chosen language without limiting functionality.

MISRA C:2012 and beyond

Although MISRA C:2012 provides an ideal basis for a language subset for any automotive safety-critical application, ISO 26262 does not dictate exactly what coding rules should be applied. With the right tools to help, development teams gain the flexibility to fine-tune the rule set to the requirements of a particular project by extending it with additional in-house rules or, with appropriate justification, by disabling selected MISRA rules (Figure 4).


Figure 4: TBvision and TBrules both allow MISRA standards to be used as the basis for company- or project-specific rule sets, so that in-house rules can be added and selected MISRA rules disabled. All versions of MISRA are supported by LDRA, ensuring complete support of both legacy and new development projects.

MISRA helps meet coding best practices

MISRA, in all its flavours, was developed to help software development teams create software applications of the highest quality. MISRA-checked code has fewer defects and it is more maintainable, readable, consistent and verifiable.

Essentially, MISRA is about applying best practices in coding, a principle underlined by the references to appropriate coding rules in ISO 26262. Understanding and meeting the requirements of MISRA C:2012 can help you meet high software-quality assurance requirements while allowing you to make better decisions about features of the programming language.

Test tools that support MISRA compliance should allow you to easily choose between versions of the standard (C, C++, Java) and appropriate subset (MISRA C:2004 for legacy and MISRA C:2012 for new projects, as well as MISRA AC for auto-generated coded), and should allow you to choose full compliance or a user-defined subset of rules that meet in-house templates or requirements.

About the Authors

Chris Tapp is a Field Applications Engineer at LDRA with more than 20 years’ experience of embedded software development. He graduated from the University of Durham in 1987 and has spent most of his career working within the automotive, industrial control and information technology industries, mainly as a self-employed consultant. He has been involved with MISRA since 2001 and is currently chairman of the MISRA C++ working group and an active member of the MISRA C working group. He has been with LDRA since 2007, where he specialises in programming standards.

Mark Pitchford has over 25 years’ experience in software development for engineering applications. He has worked on many significant industrial and commercial projects in development and management, both in the UK and internationally including extended periods in Canada and Australia. Since 2001, he has specialised in software test, and works throughout Europe and beyond as a Field Applications Engineer with LDRA Ltd.

Speak Your Mind

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!