Why can’t I use a Bug Finder tool for MISRA compliance?
With a generic programmer audience in mind, Bug Finders are engineered to produce as few false positives as possible. This avoids the frustration of expensive and time consuming investigations. However, in safety critical software development, this approach is potentially life threatening. You may also have a contractual obligation to use MISRA C/C++ for safety critical software.
MISRA C/C++ is about error prevention, not bug finding
MISRA C/C++ is an integral part of a documented software development process. When used in its proper context, it is part of an error prevention strategy. This is completely different to bug finding, which can be defined as applying automatic techniques to detect some instances of some software errors.
This is an important distinction. And one that is so rarely understood that it deserves a full and proper explanation. Here’s why:
• The violation of a MISRA guideline is not necessarily a software error
As an example, let’s consider MISRA C: 2012 Rule 11.4. This advises against converting integers to object pointers and vice-versa. There is nothing intrinsically wrong about converting an integer constant to a pointer, when it is necessary to address memory mapped registers or other hardware features.
However, such conversions are implementation-defined and have undefined behaviors (due to possible truncation and the formation of invalid and/or misaligned pointers). As such, they are best avoided everywhere apart from the rare, specific instances where they are both required and safe.
• This deviation process is an essential part of MISRA C/C++
The point of a MISRA guideline is not to say, ``you should not do that.'' It is more like a warning or alert that says, ``this is dangerous: you may only do that if it is both needed and safe. In addition, a peer should be able to easily understand why it is needed and safe.”
• MISRA C/C++ is like a guided peer review
This is a useful way to think about the MISRA C/C++ process. You are used to getting together with your colleagues to review code. MISRA C/C++ guidelines and tools act like those colleagues; they are an effective way of conducting a guided peer review to rule out most C language traps and pitfalls.
Important differences between bug finding and MISRA C/C++ compliance
• Finding some, or many, causes of run-time errors does not ensure compliance to MISRA C/C++
As Bug Finders are designed primarily for programmers not working on critical software, they are usually tolerant of false negatives, and intolerant of false positives. In the development of the Clang Static Analyzer tool, for example, we can see that everything was done to avoid false positives with very little regard to avoiding false negatives.
However, this is not the right mindset for checking compliance to MISRA C/C++ guidelines. False positives are a nuisance for programmers, and should be reduced and confined as much as possible. But, those in charge of ensuring MISRA compliance, will need tools with algorithms that have a very small rate of confined false negatives.
• MISRA C/C++ assigns great importance to reviews
The need for code readability and explainability is clearly expressed in the rationale of many MISRA C/C++ guidelines. As such, the process assigns great importance to code reviews, reviews of the code against design documents, and reviews of design documents against requirements. In fact, MISRA C: 2012 /Directive 3.1/ explicitly states that all the code must be formally traceable to the design documents.
• Use of static analysis
This traceability has some counter intuitive consequences on the use of static analysis. This is crucial both for bug finding and for the (partial) automation of MISRA C/C++ compliance checking.
Consider MISRA C: 2012 Rule 9.1. This states that the value of an automatic object must not be read before it has been set, since otherwise we have undefined behavior. For bug finding, the smarter the static analysis algorithm, the better. However, using the same smart algorithm for ensuring compliance with Rule 9.1 risks obeying the letter, but not the spirit, of MISRA C/C++.
For example, if in a specific program our smart algorithm ensures Rule 9.1 is never violated, we have ruled out one source of undefined behavior, which is good. However, in the future, other programmers, code reviewers or quality assurance people may have to:
(i) Ensure the automatic objects that are the subject of the rule are indeed initialized with the correct value
(ii) Confirm that the outcome of the tool is indeed correct.
If this takes more than 30 to 60 seconds per object, this is not good. The smart static analysis algorithm can track initializations and uses, even when they are scattered across, say, switch cases nested into complex loops.
A human cannot do this. So, ensuring compliance with respect to Rule 9.1 with deep semantic analysis is counterproductive to the final goal of the process of which MISRA C/C++ is a part.
For that purpose, it is better to use a decidable approximation of Rule 9.1, such as a suitable generalization of the Definite Assignment algorithm employed by Java compilers.
To summarize:
There is nothing wrong with Bug Finders. With projects where the MISRA C/C++ process is not an option, Bug Finders can find some coding mistakes that may be very difficult to detect otherwise. BUGSENG's ECLAIR Bug Finder can satisfy this need.
However, managers are often not aware of these two problems associated with Bug Finders:
- Bug finding is not a substitute for the MISRA C/C++ process
- Bug finders, and the static analysis algorithms they employ, are not adequate to check compliance with MISRA C/C++.
Some Bug Finders are marketed as being capable of MISRA compliance checking. This is misleading and gives a false sense of security. As this blog has shown, bug finding and MISRA compliance checking are very different.
You can find more details of the products we have designed specifically to ensure MISRA C/C++ compliance for safety critical software here.
Roberto Bagnara, Ph.D is CTO of BUGSENG, a leading provider of solutions and services for static code analysis. He is also a member of the ISO/IEC JTC1/SC22/WG14 - C Standardization Working Group and the MISRA C Working Group.