Software quality, safety, and security have become the topmost priority over the recent years. In our earlier articles, we already mentioned some events from history that entailed both large financial losses and deaths of people. The explosion of the Ariane 5, exposure of patients to a 20,000 rad overdose with the Therac-25 radiation therapy machine, 89 deaths through the fault of Toyota. All these stories have one thing in common: software bugs that led to huge losses.

So what is MISRA?

Originally, MISRA (Motor Industry Software Reliability Association) was founded for the purpose of designing a set of guidelines for development of software for microcontrollers used in road vehicles. Since then it has been adopted in every reliability and safety critical field including the automotive industry, medical devices, aerospace and defense, and so on. The MISRA standard is a document comprised of a set of rules and recommendations which C and C++ developers should stick to when developing their applications. The MISRA-C:1998 version had 127 rules.

All those rules can be grouped into the following categories:

• Mandatory
• Required – Deviations from the rules are permitted (but recommended to be documented)
• Advisory – Not obligatory

(source: What Is MISRA and how to Cook It)

The first thing to be mentioned is that the application of the MISRA standard should start before the development process actually begins, and only when it is really needed. In other cases, especially when the code base is large enough and isn't intended for use on embedded systems, the developers will have to do a long and tedious refactoring. Why so?

The source code of WinMerge is about 250 thousand lines of C and C++ code long. This is a small project, but the rule that prescribes enclosing the bodies of if statements in curly braces was broken about two thousand times in it. There are 127-228 rules like that (depending on the standard's version).

The source code of Nana, a cross-platform library for creating graphical user interfaces, is less than 100 thousand LOC long. In this project, the same rule is broken about three thousand times.

In addition to the rule about curly braces, there are a few more:

• The continue statement shall not be used;
• Every switch statement shall have a default label;
• The goto statement shall not be used;
• All if ... else if constructs shall be terminated with an else clause;

So, what is it used for?

However, these rules aren't meant to make the developer's life harder. These are the rules written in blood, and they were needed to make safety critical code less prone to bugs. The idea is that simple and clear code is less likely to contain bugs. Here are some examples of diagnostics as proof:

• Assignment operators shall not be used in expressions which return Boolean value;
• All functions that are not void should return a value;
• A loop counter shall not have essentially floating type;
• A function should have a single point of exit at the end;

Following MISRA guidelines will help enhance your software's reliability. However, those not familiar with MISRA may wonder how exactly it is used. Do you actually have to keep all those 127 rules in your head? Here's where static analyzers come to help.

What's the purpose of static analysis?

Manually checking the code for compliance with the MISRA standard is a long and tedious job. But you actually don't have to memorize all those rules. A static code analyzer can do it all for you.

Static code analysis is a process of detecting bugs and minor defects in the source code of computer programs. It can be viewed as automated code review. Some static analyzers can check code for compliance with MISRA rules, and it's these tools that are going to help you find and fix all the spots in your program that don't meet the rules. To do this, you just need to check your project with the analyzer and study the analysis report generated at the end of the check. Below I'm briefly demonstrating how to do this using the PVS-Studio analyzer and the project Shairport as an example. PVS-Studio is available for download here.

Clone the repository.

Run the build configuration script.

Run PVS-Studio in Trace Mode and build the project.

Analyze the project files based on the results of the previous step.

Convert the log into html.

Done. We can now view the log.

(source)  

So, we have learned about MISRA today: we took a look at some rules, discussed why exactly those guidelines are needed, how to apply them to your project, and so on. I hope this text was interesting enough not to make you drowsy, and still informative to make its author's work worth it. Hopefully, now you have a better understanding of what MISRA is and what static code analyzers are needed for.