MISRA-C

from Wikipedia, the free encyclopedia

MISRA-C is a C - programming standard in the automotive industry, from the English MISRA ( M otor I NDUSTRY S oftware R eliability A has been prepared ssociation). The MISRA-C programming standard defines a subset of the language scope of C , ie it includes guidelines that should lead to an increase in quality (in particular the software quality aspects of reliability and maintainability) in software development.

history

The first MISRA standard for the C programming language "MISRA C" was originally defined in 1998. There are now over 7,000 copies in circulation worldwide. It is also increasingly used in other industries for safety-critical products, e.g. B. in aircraft construction, in the military, in medicine and in rail transport.

The first standard (MISRA C: 1998) comprised 127 rules, 93 of them as regulations ( required ) and 34 as recommendations ( advisory ). The edition MISRA C: 2004 comprised 144 rules, of which 112 required , 29 advisory and 3 deprecated (out of date, rejected). The two editions refer to C89 / C90, not to the newer C standards C99 (ISO / IEC9899: 1999) or C11 (ISO / IEC9899: 2011). The current edition MISRA-C: 2012 (MISRA C Version 3) came out in March 2013 and also supports C99. In addition, it has been restructured to make it easier to understand and its content has been improved.

The MISRA standard for C ++ , MISRA-C ++: 2008 , has existed since 2008.

Objectives of the standard

The aim of the MISRA rules is to create programs so securely that they also run reliably in security-critical applications. For this purpose, MISRA C primarily gives recommendations on language constructs that are not clearly specified in the C standard, so that the manufacturer of the compiler has to choose his own interpretation, which can differ from compiler to compiler and possibly lead to the same source text on different Compilers leads to different programs. MISRA-C also contains rules that are intended to improve the readability of the source text and avoid typical errors.

If individual rules in the project or individual modules are not to be applied, a previously defined, formal process must be adhered to, whereby the deviations must also be documented. Other MISRA publications deal with other aspects of software development.

Compliance

MISRA C compliance of a code base means the regulatory compliance of the source code of a project to the guidelines of the MISRA standards. In order to prove this, a " compliance matrix " is required, i.e. a document based on which it is possible to understand which guideline is checked where and how (e.g. by compilers, static code analysis , reviews , additional project documentation, etc.). MISRA-C compliance is not synonymous with blind adherence to all rules. Deviations are also z. T. allowed. For this purpose, the MISRA-C guidelines are divided into three priority categories:

  1. “ Mandatory ” rules must be observed. Deviations are not allowed.
  2. " Required " rules should be adhered to. Deviations must be applied for via a formal deviation process, technically justified, checked and documented.
  3. " Advisory " rules should be adhered to. Deviations do not have to be formally applied for, but should be documented.

The assignment to the priority categories is different for manually implemented C-code and for C-code that was generated by means of a code generator (see Appendix E "Applicability to automatically generated code" ). The overall technical scope of the guidelines to be complied with therefore does not change, only the strictness required to comply with them.

Examples

Nested comments

Since C99, comments can be introduced with //(comment always ends at the end of the line) or with /*and */ended with any other line . However, according to the MISRA rules, the use of //is not permitted. It is also not allowed to use it again within a /* */comment /*block (nested comments).

In the following example, the ( meineFunktion()) function would not be executed because a comment was accidentally forgotten. Therefore embedded ones are /*not allowed. 

/* Kommentar, ohne Abschluss
<neue Seite>

meineFunktion();
/* Dieser Kommentar hat keine Bedeutung */

If a programmer wants to go through /*and */deactivate this section , it depends on the compiler whether it counts the comments /*like brackets or whether it */recognizes and compiles code again after the first : 

/* Code testweise deaktivieren
// i um 1 erhöhen
i++
/* Wenn Zähler i gleich a ist, MeineFunktion aufrufen um einen hoch */
if (i==a) { meineFunktion(a) }
*/

If the compiler */understands the first as the end of the comment, then the line with the will be ifcompiled and executed later. For this reason, nested comments should not be used.

Result of assignments

The following variant is bad, because you cannot understand whether the programmer made a mistake or intentionally chose this construct: 

if ( i = a )
{
   /* Anweisung */
}

The compiler would recognize this variant and translate it 

/* Zuweisung                       */
i = a;
/* dann ein Vergleich              */
if ( i != 0 )
{
   /* Anweisung */
}

The programmer may mean == and inadvertently wrote =, so that the statement should only be executed if i and a are equal: 

if ( i == a )
{
   /* Anweisung */
}

Further examples

Further examples of MISRA-C guidelines are:

  • Constants in an unsigned context must be given a Usuffix
  • Variables of the type float (floating point numbers) should not be tested with the comparison operators ==or!=
  • goto should not be used
  • Avoid magic numbers and use sensibly named constants instead:#define MAXSIZE 12
  • Prevent division by zero: if (b!=0) a/=b;
  • Ensure compiler independence, e.g. B. shift neg. Numbers:-3<<4 ==> -3*(1<<4)
  • Operator precedence is not trivial, so use parentheses:(a && b || c) ==> ((a && b) || c)
  • Avoid pointer arithmetic and check field boundaries
  • Recursion must not occur in any form (indirect or direct).
  • Implementation of strong typing

Testing tools

When programming embedded systems in the automotive environment, MISRA-C-compliant code is usually required. If the compiler cannot optionally check MISRA conformity, tools for static code analysis such as Axivion Suite, Astrée, Lint , QA-C / MISRA or RuleChecker are used for checking.

A manufacturer of tools for automatic code generation points out that some rules of MISRA-C can reduce the execution speed of the program.

literature

Some of the MISRA publications can also be purchased as PDF files on the homepage.

  • MISRA: MISRA-C: 2004 - Guidelines for the use of the C language in critical systems , ISBN 0952415623 (PDF: 095241564X)
  • Johannes Heuft: The way back to software productivity , 2007, ISBN 978-3-937446-88-2 (Chapter 5.2.4, pp. 37–41: Criticism of MISRA-C and the quality assurers who use it)

Web links

Individual evidence

  1. ↑ http://www.misra.org.uk/
  2. ↑ MISRA 2004, rule 2.2
  3. ↑ MISRA 2004, rule 2.3
  4. ↑ MISRA 2004, rule 10.6
  5. ↑ MISRA 2004, rule 13.3
  6. ↑ MISRA 1998, rule 56 and MISRA 2004, rule 10.4
  7. ↑ MISRA 2004, rule 21.1
  8. ↑ MISRA-C: 2012 Rule 10.1 - 10.8
  9. ↑ Axivion product page. Axivion GmbH, accessed on April 14, 2020 .
  10. ↑ Product page from Astrée. AbsInt Angewandte informatik GmbH, accessed on November 24, 2017 .
  11. ↑ RuleChecker product page. AbsInt Angewandte Informatik GmbH, accessed on November 24, 2017 .
  12. ↑ Articles and examples from dSpace, accessed on October 29, 2011. (PDF; 78 kB) Accessed on November 5, 2011 .