Contents
MISRA Coding Standards and Compliance
MISRA standard
MISRA is a software development standard created by the Motor Industry Software Reliability Association (MISRA) organization. The standards aim at enhancing security, portability, and reliability for the embedded software industry.
MISRA's most distinguishing features are attention to detail and ensuring security. Its authors have scrutinized international C and C++ standards and listed every possible way to make a mistake. The MISRA C and MISRA C++ standards contain a list of guidelines that help reduce the likelihood of errors and improve code readability and maintainability.
The guidelines are divided into two categories: directives and rules.
A directive is a guideline without a complete description necessary for a compliance check. In this case, the check requires additional information, which may be provided in the software design documents or requirement specifications. Static analyzers can help in checking for directive compliance. However, various tools may interpret differently, which is a non-compliance.
A rule is a guideline with a complete requirement description. It should be possible to check that the source code complies with the rule without any additional information. Static analyzers can check for compliance with rules subject to constraints.
The MISRA C 2012 rules are categorized into Mandatory, Required, and Advisory.
The Mandatory rules must never be violated under any circumstances. For example, this category includes the rule: "Do not use the value of an uninitialized variable."
The Required rules are less strict and allow for the possibility of deviations, but only if those deviations are thoroughly documented and justified in writing. The process for describing formal deviations (formal deviation process) is explained in detail in the MISRA Compliance 2020 document.
The remaining rules fall into the Advisory category. But that doesn't mean they can be ignored: they should be followed to the extent that it is appropriate to do so. Formal deviations process is optional for them, but if it is not followed, developers should take alternative measures to document and justify the deviations.
MISRA C++ 2008 slightly differs:
- directive-type guidelines are expressed by rules of the Document category;
- there are no rules in the Mandatory category; most of the rules belong to the Required category. Therefore, it is not necessary to adhere to all the rules, but all deviations must be documented.
- The standard not only describes issue, but it also provides a great deal of advice on what developers need to now before getting started, how to introduce MISRA into a development process;
- how to use static analyzers to check code for compliance;
- what documents to maintain, how to fill them out, and so on.
There are also appendices at the end that include a short list and summary table of rules, example documentation of a deviation from a rule, and several checklists.
MISRA is not just a set of guidelines, but almost an entire infrastructure for writing secure code for embedded systems.
PVS-Studio helps search for deviations from this standard. Here you can find the compliance table of PVS-Studio diagnostic rules according to the MISRA C and MISRA C++ Coding Standards. When working with MISRA standards, you can find the MISRA Compliance report useful; to generate it, you can use PVS-Studio utilities.
MISRA Compliance
MISRA Compliance is a standard that assesses whether a project is compliant with MISRA C and/or MISRA C++, considering all deviations and re-categorizations. MISRA Compliance applies to all MISRA Association standards. Here we consider the use of MISRA Compliance on the example of the MISRA C 2012 standard.
MISRA C 2012 guidelines states that compliance is unreasonable or even impossible in some cases. When deviations from the rules occur, they must be documented. However, it can be troublesome to ensure that the program ultimately meets this standard. This is where the MISRA Compliance standard proves invaluable.
How to obtain MISRA Compliance
The key is to understand whether a project complies with MISRA C 2012 or not. To do this, one needs to get a GCS (Guideline Compliance Summary). The GCS is a table where each entry contains the following set of attributes: the guideline name, its level, and whether the project meets it. Here is an example of what it should look like:
The guideline number and its default category are taken from the standard. However, MISRA Compliance allows you to change (re-categorize) the guideline level, although this is optional. Each specific user can adjust a specific project according to a guideline re-categorization plan (GRP). The GRP is a valid set of re-categorizations from one level to another. This is what it looks like in a table:
For example, there is a Rule 1.1 that has a Required level. According to the table, one can change the warning level to Mandatory or leave it unchanged (indicated by green cells). However, downgrades to Advisory or Disapplied is not allowed (indicated by red cells).
Based on the resulting guideline categories, developers can adjust a compliance level. Possible compliance options for MISRA categories look like this:
This table shows whether a project complies with MISRA C 2012. If there is at least one compliance that falls in the red cells (table above), then the project does not comply with the standard.
To keep things simple, let's explore again the Rule 1.1 with the default category value of Required. In the table, we can see that the acceptable compliance values for Required are Compliance or Deviations. The paragraph below explains specifications of these statuses more. That is, if the project complies with the Rule 1.1 or complies but with deviations, then all is well, and one can move on to the next rule. If at least one compliance falls in the red zone (table above), the project isn't in compliance with MISRA C 2012. If all rules have only allowable values (fall only in the green zone), then the project meets the MISRA C 2012 standard.
Let's move on to generating the MISRA Compliance report.
How to generate a MISRA Compliance report in PVS-Studio
To generate a report, use the PlogConverter.exe (Windows) or plog-converter (Linux, macOS) utility. These utilities are included in distributions. At the moment of writing this article, PVS-Studio can generate the compliance report only for the MISRA C 2012 standard.
To generate a MISRA Compliance report, perform the analysis (here is a guide for Windows and for Linux / macOS). Note that all MISRA-related diagnostic rules should be enabled, otherwise the coverage of MISRA rules is reduced. How to check if all rules are enabled is described in the above links to the analysis documentation.
Then use one of the report conversion utilities. Here is an example of how to run PlogConverter.exe:
"C:\Program Files (x86)\PVS-Studio\PlogConverter.exe" "path_to_report_file" ^
-t MisraCompliance -o "path_to_MISRA_report" --grp "path_to_grp.txt"A sample command for plog-converter:
plog-converter "path_to_report_file" -t misra-compliance \
-o "path_to_MISRA_report" --grp "path_to_grp.txt"The report is in an HTML format, which is convenient for printing. Here is an example of a report when a project does not comply with MISRA C 2012:
An example of a report when a project complies with MISRA C 2012:
Look at the column description:
- Guideline contains the rule and directive numbers of the MISRA C standard;
- Category contains the category of the rule or directives specified in the standard;
- Re-categorization contains the category after re-categorization according to GRP;
- Compliance contains the compliance status of the checked code with a rule or directive. What prevents compliance with the MISRA C 2012 standard is highlighted in red.
In this case, the GRP is a txt file. Here is an example of the file contents with valid level changes:
Rule 2.1 = Mandatory
Rule 8.13 = Required
Directive 4.3 = Mandatory
Rule 2.6 = DisappliedIf this file contains a category downgrade, the utility will issue an error message and will not generate a report. The exception to this is the Advisory category, which can be downgraded to Disapplied. This is how the categories are arranged from most important to least important:
The compliance statuses of the checked code mean the following:
- Compliant. There are no deviations in the project for this guideline.
- Deviations. Deviations from the guideline are detected and documented. Mark a warning as false alarm (see Mark as False Alarm) if you want the utility to treat a particular warning as Deviation instead of Violation. The number of confirmed deviations is indicated in parentheses.
- Violations. There is at least one deviation from the guideline that has not been documented. The number of such deviations is indicated in parentheses. If, in addition to Violations, Deviations are also detected for a guideline, both statuses will be displayed.
- Disapplied. The guideline does not apply to the project and will be ignored. It applies only to the Advisory guidelines.
- Not Supported. This analyzer does not support the guideline.
The key part is to conclude whether the project complies with MISRA C 2012 or not. The code complies with the standard if:
- all Mandatory guidelines have a Compliant status;
- all Required guidelines have a Compliant and/or Deviations status;
- all Advisory guidelines can have any status;
- all Disapplied guidelines are ignored.
Was this page helpful?
