MISRA-C

MISRA -C is a C programming standard in the automotive industry, from the English MISRA (Motor Industry Software Reliability Association) was developed. The first MISRA standard for the C programming language " MISRA C" was originally defined in 1998. There are now over 7000 copies in circulation worldwide. In other industries it is increasingly used for safety- critical products, such as in aircraft, military, medical and rail transport.

The first standard ( MISRA C: 1998) consisted of 127 rules, of which 93 as a requirement (required) and 34 recommendations ( advisory ). The output MISRA C: 2004 included 144 rules, of which 112 required, 29 advisory and 3 deprecated ( outdated, rejected). The two issues refer to C89/C90, not the newer C standard C99 ( ISO/IEC9899: 1999 ) or C11 ( ISO/IEC9899: 2011). The current edition of the MISRA -C: 2012 ( MISRA C version 3) has come out in March 2013 and also supports C99. She was also reorganized to improve readability and content.

Since 2008, the MISRA standard for C , MISRA C : 2008.

The aim of the MISRA rules is to create programs safely, so that they run reliably in safety-critical applications. These are MISRA C especially recommendations for language constructs that are specified unclear in the C standard, so that the manufacturer of the compiler has to choose one's own interpretation, which may vary from compiler to compiler and possibly leads to the same source code on different compilers leads to different programs. MISRA -C also contains rules which are intended to improve the readability of the source code and avoid some common pitfalls.

If individual rules in the project or individual modules should not be used as a pre-defined, formal process must be complied with, the deviations must be documented. Other MISRA publications deal with other aspects of software development.

Examples

Comments can also be introduced in C with / * and in any other line * / ended with both / / ( comment always ends at end of line ) as. After the MISRA rules, the use of / / is not allowed. Likewise, it is not allowed within a / ** / comment block one more time / * to use ( nested comments ).

In the following example, the function ( myFunction ()) would not run because accidentally a comment statements have been forgotten. Therefore, embedded / * not allowed.

/ * Comment, not finish   myFunction (); / * This comment has no meaning * / Will a programmer this section by / * and * / disable, so it depends on the compiler, whether he / * counts as brackets in comments, or if he recognizes and compiled code to the first * / again:

Disable / * code for testing purposes / / I increase by 1 i / * If counter i is a, My function call to a high * / if ( i == a) { myFunction ( a) } * / When the compiler first * / understood as the end of the comment, then the line is compiled with the if and later executed. For this reason you should not work with nested comments.

The following variant is bad because you can not understand, if the programmer has made ​​a mistake, or has deliberately chosen this construct:

If ( i = a) {     / * Statement * / } The compiler would recognize and translate this variant

/ * Assignment * / i = a; / * Then a comparison * / if ( i! = 0) {     / * Statement * / } Maybe programmer meant == and = has inadvertently written so that the instruction is to be executed only on parity of i and a:

If ( i == a) {     / * Statement * / } Other examples are:

  • Constants in an unsigned context must be provided with a U suffix
  • Variables of type float ( floating point ) should not be tested with the comparison operators == or! =
  • Goto should not be used
  • Avoid magic numbers and instead use sensible named constants: # define MAXSIZE 12
  • Prevent division by zero: if ( b! = 0) a / = b;
  • Ensure independence compiler, such as shift your neg numbers: -3 >> 4 == > -3 * (1 >> 4 )
  • Operator Precedence consequences are not trivial, so use parentheses: ( a && b | | c ) == > ((a && b ) | | c )
  • Avoid pointer arithmetic and array bounds check
  • Recursion may occur in any form ( neither directly nor indirectly ).

Tools

During the programming of embedded systems in the automotive environment MISRA -C compliant code is usually prescribed. If the compiler can not check the optional MISRA compliance, tools for static code analysis as QA-C/MISRA or Lint be used for verification.

A manufacturer of tools for automatic code generation refers to the fact that some rules of MISRA -C lead to performance degradation.

575639
de