MISRA C

History

MISRA C is now in its third edition.

MISRA C:1998

In spring 1997 software engineers at the Austin Rover Group (ARG) sent a draft C coding standard to Programming Research Ltd (PRL) for review. The review was performed by PRL's then senior consultant, David Blyth, who proposed replacing the draft with an appreciably stronger set of coding rules. Those rules, with minor changes, formed the basis of the first edition of MISRA C, "Guidelines for the use of the C language in vehicle based software", which was published in 1998 and is officially known as MISRA-C:1998.

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

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: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

In 2013, 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.

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

In April 2016, MISRA published (as free downloads) Amendment 1 to MISRA C:2012 which added fourteen new security guidelines, together with Addendum 2 to MISRA C:2012, which outlines the coverage of MISRA C:2012 against ISO/IEC TS 17961:2013 - C secure coding rules.

MISRA Compliance:2016

In April 2016, MISRA published MISRA Compliance:2016, which provides enhanced guidance on achieving compliance to MISRA C and MISRA C++.

Guidelines

When a new software project is started, the latest MISRA standard should be used. Previous standards are still available for use with legacy software projects that need to refer to it.

For the first two editions of MISRA-C (1998 and 2004) all Guidelines were considered as Rules. With the publication of MISRA C:2012 a new category of Guideline was introduced - the Directive whose compliance is more open to interpretation, or relates to process or procedural matters.

Classification

Each Guideline is classified as Mandatory (new for MISRA C:2012), Required or Advisory. Furthermore, the MISRA Compliance document permits Advisory guidelines to be Disapplied

MISRA C:2012 separately classifies each guideline as either Single Translation Unit or System. Additionally, the rules are classified as Decidable or Undecidable.

Categorization

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

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; proof must be provided 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:

Tools

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

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.

Criticism

Some research results question the effectiveness of MISRA.

In a paper that compares earlier work on MISRA C:1998 with MISRA C:2004, Les Hatton comes to the conclusion that:

"In view of the apparent widening influence of the MISRA C standard, this paper attempts to assess whether important deficiencies in the original standard have been addressed satisfactorily. Unfortunately, they have not and the important real to false positive ratio is not much better in MISRA C 2004 than it was in MISRA C 1998 and it is unacceptably low in both."

He goes on to state:

"In its present form, the only people to benefit from the MISRA C 2004 update would appear to be tool vendors and it is to be hoped that steps will be taken both to simplify the wording and to reduce the false positive ratio in future revisions by taking a little more notice of published experimental data and being less tempted to invent rules on the basis that they seem a good idea."

A study at the TU Delft, by Cathal Boogerd and Leon Moonen, empirically assesses the value of MISRA C:2004. It comes to similar results:

"From the data obtained, we can make the following key observations. First, there are 9 out of 72 rules for which violations were observed that perform significantly better (α = 0.05) than a random predictor at locating fault-related lines. The true positive rates for these rules range from 24-100%. Second, we observed a negative correlation between MISRA rule violations and observed faults. In addition, 29 out of 72 rules had a zero true positive rate. Taken together with Adams’ observation that all modifications have a non-zero probability of introducing a fault, this makes it possible that adherence to the MISRA standard as a whole would have made the software less reliable."