Automating Compliance to MISRA C/C++ Standards

Paul Humphreys

November 03, 2009

Paul HumphreysNovember 03, 2009

Thanks to their inherent flexibility and potential for portability across a wide range of hardware, C and C++ have become the languages of choice for the development of real-time embedded applications within the automotive industry.

C and C++ have most of the features a software development team could wish for and, in the right hands, can be used to write well laid out, structured, and expressive code. In the wrong hands, this flexibility can lead to perverse and extremely hard to understand code.

The Motor Industry Software Reliability Association (MISRA) has done much to promote best practice guidelines for the C, and now C++, languages. In 1998, MISRA published their C standard to promote the use of "safe C" in the UK automotive industry, which was updated and re-released as MISRA-C:2004.

Widely accepted as a "safe-subset" for use in the C language, the MISRA guidelines draw from a variety of sources, but in particular address the issues highlighted in the ISO standard regarding unspecified, undefined, and implementation-defined behavior.

MISRA-C does not comment on the suitability of C for use in safety-critical systems, but in recognition of the widespread use of C, aims to promote the safest possible use of the language. Similarly the suitability of C++ is not judged, and was in any case outside the scope of the 2004 guidelines.

However, in response to the increasing popularity of C++, and despite the presence of existing guidelines such as the Air Vehicle (AV) C++ coding standards from Lockheed Martin, MISRA followed its work with C by defining a suitable subset of C++, namely MISRA-C++:2008, launched in June 2008. As C++ becomes a more significant player in the automotive space, no doubt this standard will play a more dominant role.

What do the rules look like?
For each rule, MISRA-C offers a rule number, category, requirement text and source reference. The motivation for the rule is given, and typically an example of non-compliant code is supplied. The following rule in Table 1 below is taken from section 9 of MISRA-C:2004 and ensures that all automatic variables are assigned values prior to being used:

As you can see from this example in Table 2 below , MISRA-C++:2008 follows a similar style:

The MISRA compilation of rules is enormously valuable. However, if there was no way to automatically apply these rules to your code, they would have very little impact on software quality. Indeed, MISRA-C places great emphasis on the use of static analysis tools to enforce compliance with the safer subset of C.

Many of the rules would be extremely complicated to check manually as they involve tracing data flow across system components and tracking properties such as the underlying type of variables.

Underlying type is a concept introduced by MISRA as part of its rigorous approach to strong typing and declarative consistency. Several sections of the document are dedicated to preventing type conversions deemed unsafe, unnecessary or non-explicit.

<><><><><> has automated 90% of the 141 MISRA-C:2004 rules in its TBmisra product. Of the unsupported rules, 14 standards are not deemed to be statically analyzable by a tool and are documented in the LDRA reports as such, but in some cases still receive a degree of support via another technique such as run-time analysis.

< Previous
Page 1 of 2
Next >

Loading comments...

Most Commented

  • Currently no items

Parts Search