Yet another technical committee has spent thousands of man-hours developing yet another set of rules for programmers to follow. Not excited yet? In the case of the latest version of MISRA, you may be in for a pleasant surprise.
The MISRA C Working Group, of which I am a member, has recently announced MISRA C:2012, the latest version of the coding guidelines that have become a de facto standard for automotive, medical, mil/aero and other applications on which human lives depend. Companies throughout these industries rely on MISRA to help them improve the quality of software that can literally mean the difference between life and death, and to mitigate liability by meeting a standard set of rules against which that quality can be measured. Essentially, MISRA gives developers a set of coding best practises for high-stakes software.
So what does MISRA C:2012 offer that’s new?
To answer that, let’s take a step back.
MISRA C was first published in 1998 (MISRA C:1998) to provide a "restricted subset of a standardised structured language" for automotive systems. The adoption of MISRA C in an unexpectedly wide range of industrial sectors far exceeded the original expectations, and after extensive feedback, a revision (MISRA-C:2004) was published that addressed a number of issues highlighted in use. Nothing remains unchanged—certainly not in the software world—and over time the base language had moved on and the standard needed to be updated again. That brings us to the latest version, MISRA C:2012, which is designed to:
- Correct issues found in the 2004 version
- Add support for C99 while retaining support for C90
- 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 rules include a detailed rationale and remove rules without strong rationale
- Include guidance on the applicability of rules to automatically generated code
- Make rules more precise so that they will not prevent reasonable uses or behaviours that have no undesirable consequences
- Provide better guidance on rules enforcement, such as whether a rule defines a general behaviour across a project, or only specific cases
- Define rules as “decidable”—those against which an analysis tool can always determine compliance or non-compliance— versus undecidable, in which this is not the case (generally due to pointer or data values affecting control flow), in order to allow better tool enforcement andfocus manual checking more precisely, saving time and money
I’m confident that the newest version of MISRA will help developers take advantage of more popular features of the C language while spending less time on compliance efforts.
In an article I co-wrote with LDRA’s Mark Pitchford (see “MISRA C:2012: Plenty of Good Reasons to Change”) we outline many of the details of what has changed in the latest MISRA rules, including specific examples of programming approaches. I encourage any developer who is working on an application that has a safety-critical aspect to look into this new release. Even if your application doesn’t require specific industry certifications, there are advantages to being able to prove that your code was developed to the most stringent quality standards available. New test tools that support MISRA compliance will allow you to choose between versions of the standard (for both legacy and new projects), and allow you to choose full compliance or a user-defined subset of rules that meet in-house templates or requirements.
Ultimately, 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.