Code quality is particularly important in mission- or safety-critical systems. Since IAR Embedded Workbench performs type checking during the linking process and also runs extensive diagnostics, the generated code is very reliable. With the introduction of the MISRA C checker, also the software safety requirements of the automotive industry are supported.

What is MISRA C Checker?

MISRA C is a software development standard for the C programming language developed by MISRA¹. Its aims are to facilitate code safety, portability and reliability in the context of embedded systems, specifically those systems programmed in ISO C.

The first edition of the MISRA C standard, “Guidelines for the use of the C language in vehicle based software”, was produced in 1998, and is officially known as MISRA-C:1998.

In 2004, a second edition “Guidelines for the use of the C language in critical systems”, or MISRA-C:2004 was produced, with many substantial changes to the guidelines, including a complete renumbering of the rules.

• MISRA-C:1998: 127 rules (93 – required, 34 – advisory)
• MISRA-C:2004: 141 rules (121 – required, 20 – advisory), divided into 21 topical categories, from “Environment” to “Run-time failures”.

¹MISRA, The Motor Industry Software Reliability Association, is a collaboration between vehicle manufacturers, component suppliers and engineering consultancies which seeks to promote best practice in developing safety-related electronic systems in road vehicles and other embedded systems.

Who should use MISRA C?

Compliance with the MISRA C guidelines is a requirement in many automotive companies but could be beneficial in any development organization. The guidelines enforce sound coding practices and address the ambiguities of C; they help developers write code in a consistent manner and avoid confusing constructions.

How does it work?

The MISRA C checker is completely integrated with IAR C/C++ Compiler. From IAR Embedded Workbench, you can control which MISRA C rules are checked; the settings will be used for both the compiler and the linker.

The implementation of the MISRA C rules does not affect code generation, and has no significant effect on the performance of IAR Embedded Workbench. The compiler and linker only generate error messages, they do not actually prevent you from breaking the rules you are checking for. You can enable or disable individual rules for the entire project or at file level. A log is produced at compile and link time, and displayed in the Build Message window of the IAR Embedded Workbench IDE. This log can be saved to a file, as described in the IAR Embedded Workbench User Guide.

A message is generated for every deviation from a required or advisory rule, unless you have disabled it. Each message contains a reference to the MISRA C rule deviated from.The format of the reference is as in the following error message:

Error[Pm088]: pointer arithmetics should not be used (MISRA C 2004 rule 17.4)

Note: The numbering of the messages does not match the rule numbering.

For each file being checked with MISRA C enabled, you can generate a full report containing a list of:

• All enabled MISRA C rules
• All MISRA C rules that are actually checked.

MISRA C compliance

To claim compliance with the MISRA C guidelines for your product, you must demonstrate that:

• A compliance matrix has been completed demonstrating how each rule is enforced.
• All C code in the product is compliant with the MISRA C rules or subject to documented deviations.
• A list of all instances where rules are not being followed is maintained, and for each instance there is an appropriately signed-off documented deviation.
• You have taken appropriate measures in the areas of training, style guide, compiler selection and validation, checking tool validation, metrics, and test coverage, as described in section 4.2 of Guidelines for the Use of the C Language in Critical Systems.