MISRA Compliance:2020 — MISRA Rules and MISRA Guidelines
MISRA rules and guidelines are outlined in MISRA Compliance:2020, which consolidates and clarifies much of the guidance that was previously spread across the MISRA C and C++ coding guideline documents.
This is to help both software “acquire” and “supplier” organizations have a clear understanding of what MISRA compliance means at the outset of a project.
In the second portion of MISRA Compliance:2020, the document outlines the best practices for enforcing MISRA rules and MISRA guidelines, and how to manage MISRA deviations.
Read along or jump ahead to the section that interests you the most:
➡️ easily enforce misra rules with helix qac
Back to topHow to Enforce MISRA Rules and Directives
A perfect static analysis tool would identify every MISRA rule violation and generate no false positives. Unfortunately, every MISRA checker has its limits. This is because while most MISRA rules are decidable, some of them are undecidable.
Section 3 of the compliance document provides a useful explanation of the concept of decidability.
MISRA Rules and Directives
The MISRA C:2012 Guidelines classify each guideline as either a rule or a directive.
Compliance with a directive cannot be determined through examination of the source code alone — reviews of processes, documentation or functional requirements are needed in order to determine full compliance with directives.
And, compliance with a rule can be determined through examination of the source code alone, so static source code analysis tools can be used to determine compliance with rules.
Unfortunately, there are some rules for which it is impossible for any tool to provide a 100% definite answer to the question “Does the code comply with this rule?”. There will be some situations where compliance is uncertain.
The MISRA Compliance:2020 explains that the capability to diagnose non-compliance to undecidable rules varies widely between different tools.
And, it stresses the importance of using a tool that delivers a high degree of success in reporting and distinguishing definite violations as well as possible violations in order to avoid both false positives and false negatives.
Analysis tools that reliably detect possible violations can help to eliminate uncertainties through the adoption of best-practice coding techniques.
Example Undecidable Rule
Consider Rule 12.2: “The right-hand operand of a shift operator shall lie in the range zero to one less than the width in bits of the essential type of the left-hand operand”.
This rule prevents undefined behavior that would result from left-shifting or right-shifting a value by an invalid number of bits.
For the code below, where the right-hand operand is a constant value, it is easy for a tool to detect the rule violation:
extern unsigned long ula;
extern void foo(void)
{
ula = ula << -2; /* 2790 */
ula = ula << 40; /* 2790 2921 */
}
Helix QAC generates message 2790: “Constant: Right-hand operand of shift operator is negative or too large”.
(Helix QAC also generates message 2921: “Definite: Left shift operation on expression of unsigned type results in loss of high order bits”. because it detects that in this context there will always be a loss of high order bits.)
However, consider the example below:
void foo(unsigned long ul, int si)
{
if (si > 40)
{
}
ul = ul << si; /* 2792 */
}
In this case, the value of the right-hand operand (such as the number of bits to be shifted) may be out of range sometimes (assuming the size of a long is 32 bits).
Unless the if statement is redundant, the code implies that the value of si is expected to exceed 40 sometimes — and if it does, the behavior of the subsequent shift operation will be undefined.
In this case, Helix QAC generates message 2792: “Apparent: Right-hand operand of shift operator is negative or too large.”
Helix QAC’s sophisticated data flow analysis takes a complete system-wide view across all the translation units in your program in order to determine whether issues are definite or possible.
This is just one of the reasons why every one of the top 10 global automotive parts suppliers relies on Helix QAC for their MISRA compliance needs.
📕 Related Content: Check out our MISRA C Resource Guide
Back to topHow to Enforce MISRA Guidelines
Even though the MISRA coding guidelines explicitly exclude coding style considerations, MISRA Compliance:2020 does recognize the importance of using a consistent coding style to make it easier for programmers to understand code that has been written by others.
Section 2.4 of the compliance document recommends that all organizations define a “house style”, covering issues such as code layout and use of indenting; layout of braces and block structures; naming conventions; and use of comments.
What's more, MISRA Compliance:2020 specifically references C Style: Standards and Guidelines by David Straker.
Helix QAC includes a component — “Namecheck” — that can help ensure compliance with your house naming conventions. You can configure QAC to always run Namecheck alongside your MISRA C, or C++ analysis.
By running Helix QAC's MISRA rule checker along with a configured Namecheck, you can catch as many coding issues as possible before testing and manual code review.
Back to topHow to Manage MISRA Metrics
Collecting metrics is essential for measuring — and improving — your code quality.
Section 2.5 of the compliance document highly recommends the use of a tool to collect source code metrics to identify areas of the code that need more focused reviews and testing efforts.
Metrics can also help to prevent the creation of code that is hard to test and maintain.
The document does not prescribe exactly which metrics should be used on a MISRA-compliant project, as that should be determined based on the nature of the project.
Typically, overall code quality is broken down into a set of goals, including “reliability”, “testability”, “maintainability”, and others.
Metrics relating to these quality goals are used to measure the extent to which these goals have been achieved and to monitor code quality trends over time.
For example, increasing code complexity and/or an increasing number of defects are likely to negatively impact reliability goals.
Increasing code complexity will also reduce maintainability — along with other factors such as increased code size and tighter coupling between modules.
Helix QAC produces metric data at the same time as it checks your code for MISRA compliance. It produces file and function-based metrics for C code, and adds class-based metrics for C++ code.
It can generate warning messages whenever a metric exceeds your chosen threshold. This means that any metric threshold violations can be addressed straight away by developers before code is committed.
Back to topHow to Manage MISRA Deviations
Most projects will need to break one or more of the MISRA rules.
Section 4 of the compliance document states that rule violations are sometimes unavoidable.
A rule violation does not mean that your code cannot be MISRA compliant. The important thing is that any rule violations are have been properly considered, authorized, and formally documented as a “deviation record”.
A deviation can apply to a single instance of a rule violation, or it can apply to a use case that occurs in multiple places throughout the code.
It is important to be able to identify every instance of the violation associated with a deviation record to support a robust review process.
The document recognizes that there are frequently encountered use cases that require deviations. And, in order to save project effort, “deviation permits” may be used to justify those deviations.
A repository of deviation permits could be agreed by the supplier and the acquirer at the outset of a project in order to save time once the project is underway.
Using Helix QAC in conjunction with the Helix QAC Dashboard makes it easy to manage your MISRA deviations.
Helix QAC’s “diagnostic suppression” feature allows you to hide diagnostics from users, for which there are legitimate reasons to deviate from full compliance to coding standards. These suppressions may be linked to deviation records that are all stored in the dashboard’s database.
So, the system maintains your repository of deviation records, together with the list of all instances of associated violations. This can be output as part of your compliance report, using the “suppression deviation list” report component.
Project-based permission settings can be used to restrict which users are able to add and remove suppressions and deviations. In this way, only those users with the appropriate level of authority can suppress diagnostics and create deviations.
This native support for a MISRA-compliant deviation process is one more reason why Helix QAC has been chosen by hundreds of organizations developing mission-critical systems worldwide.
Back to topUse Helix QAC to Enforce MISRA Rules and MISRA Guidelines
Helix QAC finds and reports on violations of MISRA rules, guidelines, and deviations in C and C++. It is the best static code analyzer for MISRA C and C++ because it is:
- Fully documented rule enforcement and message interpretation.
- Fully configurable rules processing.
- Independently certified for use in the development of safety-critical software.
- Supplied with extensive example code.
➡️ Read Our MISRA Compliance Overview
In addition, you can register for a Helix QAC demo to see how the static analyzer helps you comply with MISRA and other functional safety standards.
➡️ Sign Up for Your Helix QAC free trial
Back to top