The intent of the Motor Industry Software Reliability Association (MISRA) C coding standard was to define a subset of the C language that minimizes the possibilities of errors. Although originally intended for safety critical applications in the automotive market, it is being used in other areas such as medical and aerospace. There are also software teams using the standard as a way to improve the quality and security of their code but don’t necessarily require the standard for compliance to a safety or security standard. MISRA C is a well-known and respected standard and it’s catching on in other markets.
The goal of MISRA is to deliver better code during the development process. Applying the MISRA rules to code that’s already been written, tested and/or deployed isn’t an easy task. The question is whether it makes business sense to make changes to an existing code base that has been proven to be reliable, with the risk of introducing new problems while making the changes. This post considers some pragmatic approaches to adopting MISRA gradually with the help of static application security testing (SAST) tools like CodeSonar from GrammaTech.
What is the goal?
The approach to adopting a new coding standard depends on what the requirement of the new system is.
- If the requirement is to achieve full MISRA compliancy, then the existing code base will have to be made compliant. CodeSonar can certainly help in this situation, but it is not the focus of this blog post.
- If, instead, MISRA is used to deliver better code going forward, then this post provides an interesting approach.
MISRA C Guidelines
It’s important to realize that not all MISRA C guidelines are created equal. Guidelines are either rules or directives, the difference being that rules are completely described in the standard and compliance to a rule can be verified, usually automatically with static code analyzers. A directive is less defined and needs additional information, usually provided during an audit, to ensure compliance. For the sake of this post, we’ll be talking about MISRA C guidelines as coding standard rules.
Coding standards usually classify rules by severity and MISRA C is no different. MISRA C rules fall into three categories, mandatory, required and advisory. Predictably, the mandatory rules are the most critical and the advisory less so. If the plan is to use MISRA C to avoid the most egregious errors, your team can decide to ignore the advisory rules, at least initially.
The first step in adopting MISRA C is to review the set of rules and select which advisory rules are most applicable to the application at hand, thereby creating your own MISRA subset. This is a completely legitimate approach which newcomers overlook feeling that it’s an “all or nothing” set of rules and, consequently, overwhelming. If your organization is planning to use MSRA C as a basis for your own custom coding standard, without the need for full MISRA C compliance, then further selection is possible.
“Stop the Bleeding”
Of course, applying MISRA C to an existing code base can be a big investment, you may have thousands of violations to evaluate, which is not always useful as your code is already tested and shipped. Changing working code to make it compliant with a coding standard is not always a good investment. What may be more financially viable is to start by making sure that your new code is MISRA C compliant.
The way to achieve this with CodeSonar is to run an analysis on your entire source code base and highlight the violations. You can then use these results as a baseline to compare against. We go into more detail on adopting SAST into an existing code in this post. This comparison now only highlights MISRA violations in new code developed after the baseline. This new code can either be in new files, or even added to existing files. MISRA rule violations can be fed to the developer right in their IDE, effectively, “stopping the bleeding.”
A Pragmatic Approach to Adopting MISRA C
A way for developers to ease their way into using a new coding standard means some preparation ahead of time in order to lower the chance of the team being overwhelmed with reports. The following steps provide a quick summary of the steps needed:
- Define a rule set for the project: It’s possible that you already have a coding standard, and as such you may be looking at MISRA C as a way to extend what you have. If not, and full compliance is not the end goal, it’s a good idea to decide which rules the team plans to adopt.
- Configure CodeSonar to support the ruleset defined by the team. It makes sense, of course, to keep various bug and security vulnerability rules enabled as well.
- Use filtering to focus on the most critical violations. Once a baseline report has been generated, CodeSonar has powerful filtering and saved search capabilities to help developers focus on the most critical violations first. It’s also possible to filter on just the changes in the last build, assess violations by type, severity or by file.
- Concentrate on new code first. Depending on the preferred approach, the baselines report can be filtered out by setting the state of the existing violations to “defer” or simply filter new reports bases on the deltas between builds. In either case, the focus of the assessment is on changes to the code or new code written.
- Assess and prioritize violations. It’s important to assess violations in new code as they arise and by this, we mean analyze whether the violation is real, decide whether it needs to be fixed and assign a priority to the fix. This shouldn’t be too onerous when concentrating on new code. However, the team can get overwhelmed if violations aren’t managed with each iteration.
- Evaluate existing code, as time allows, in severity order. If the team decides to look at the state of the existing code (before the baseline and before we “stopped the bleeding”) then it makes sense to consider the highest severity violations first. This is where CodeSonar’s powerful search, sorting and filtering capabilities are useful. Assessments can be made on the mandatory rules first, for example, and fixes can be assigned and prioritized.
Summary
Adopting MISRA C to an existing project that doesn’t require official compliance can still be a daunting undertaking without a thoughtful approach. This pragmatic approach concentrates on new code, initially, and evaluating coding standard violations in severity order. CodeSonar provides the support for both MISRA C and configuration options, filtering and searching functionality that makes this pragmatic approach a reality for software developers.
To learn more, we welcome you to download a read this white paper, “Accelerating MISRA Automotive Safety Compliance with Static Application Security Testing.”
