MISRA C

From Infogalactic: the planetary knowledge core
Jump to: navigation, search

Lua error in package.lua at line 80: module 'strict' not found.

MISRA C is a set of software development guidelines for the C programming language developed by MISRA (Motor Industry Software Reliability Association). Its aims are to facilitate code safety, portability and reliability in the context of embedded systems, specifically those systems programmed in ISO C. There is also a set of guidelines for MISRA C++. MISRA has evolved as a widely accepted model for best practices by leading developers in sectors including aerospace, telecom, medical devices, defense, railway, and others.[1][2][3] MISRA C is not an open standard; the guideline documents must be bought by users or implementers.[4]

History

The first edition of MISRA C, "Guidelines for the use of the C language in vehicle based software", was produced in 1998, and is officially known as MISRA-C:1998.[5]

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.

As of 18 March 2013, the release of MISRA C:2012 was announced. MISRA C:2012 extends support to the C99 version of the C language (while maintaining guidelines for C90), in addition to including a number of improvements that can reduce the cost and complexity of compliance, whilst aiding consistent, safe use of C in critical systems.[6]

Rules

MISRA-C:1998 has 127 rules, of which 93 are required and 34 are advisory; the rules are numbered in sequence from 1 to 127.

MISRA-C:2004 contains 142 rules, of which 122 are "required" and 20 are "advisory"; they are divided into 21 topical categories, from "Environment" to "Run-time failures".

MISRA-C:2012 contains 143 rules (each of which is checkable using static program analysis) and 16 "directives" (that is, rules compliance with more open to interpretation, or relates to process or procedural matters);[7] each of which is classified as "mandatory", "required", or "advisory"; separately classified as either "Single Translation Unit" or "System".[7] Additionally, the rules are classified as Decidable or Undecidable.

The rules can be divided logically into a number of categories:

  • Avoiding possible compiler differences, for example, the size of a C integer may vary but an INT16 is always 16 bits. (C99 standardized on int16_t.)
  • Avoiding using functions and constructs that are prone to failure, for example, malloc may fail.
  • Produce maintainable and debuggable code, for example, naming conventions and commenting.
  • Best practice rules.
  • Complexity limits.

Compliance

In order for a piece of software to claim to be compliant to the MISRA C Guidelines, all mandatory rules shall be met and all required rules and directives shall either be met or subject to a formal deviation. Advisory rules may be disapplied without a formal deviation, but this should still be recorded in the project documentation.

Note: For compliance purposes, there is no distinction between rules and directives.

Deviations

Many MISRA C rules can be characterized as guidelines because under certain condition software engineers may deviate from rules and still be considered compliant with the standard. Deviations must be documented either in the code or in a file. In addition to proof that the software engineer has considered the safety of the system and that deviating from the rule will not have a negative impact, requirements for deviations also include:

  • The rule deviated from.
  • Rationale for deviation.[8]

Tools

While there exist many software tools that claim to check code for "MISRA conformance", there is no MISRA certification process.[9]

An exemplar suite for MISRA-C:2004 is available from the MISRA Forum, which allows tool users to evaluate and compare the checking support provided by the various MISRA tools. Additionally, it gives tool implementers some guidance as to the intent of the Rules within MISRA-C:2004.

Most of the guidelines can be checked using tools that perform static code analysis. The remaining guidelines require the use of dynamic code analysis.

Tools that check code for MISRA conformance are
C compilers that support MISRA conformance are

See also

References

  1. Lua error in package.lua at line 80: module 'strict' not found.
  2. Lua error in package.lua at line 80: module 'strict' not found.
  3. Lua error in package.lua at line 80: module 'strict' not found.
  4. Lua error in package.lua at line 80: module 'strict' not found.
  5. Lua error in package.lua at line 80: module 'strict' not found.
  6. Lua error in package.lua at line 80: module 'strict' not found.
  7. 7.0 7.1 Lua error in package.lua at line 80: module 'strict' not found.
  8. Achieving MISRA C:2012 Compliance Achieving MISRA C:2012 Compliance
  9. "MISRA C FAQ list." MISRA Consortium
  10. MISRA conformance checking, PC-lint/FlexeLint, Gimpel Software.

External links

  • No URL found. Please specify a URL here or add one to Wikidata.
  • Lua error in package.lua at line 80: module 'strict' not found.
  • Lua error in package.lua at line 80: module 'strict' not found.
  • Lua error in package.lua at line 80: module 'strict' not found.
  • Lua error in package.lua at line 80: module 'strict' not found.
  • Lua error in package.lua at line 80: module 'strict' not found.
  • Lua error in package.lua at line 80: module 'strict' not found.
  • Lua error in package.lua at line 80: module 'strict' not found.
  • Lua error in package.lua at line 80: module 'strict' not found.
  • Lua error in package.lua at line 80: module 'strict' not found.