Help! Are compiler defects bugging my code?
One of the major hazards safety-critical software projects have to take into account is that compilers can (a) inject defects in the running code, and (b) fail to diagnose invalidity/inconsistencies in the source code and then transform that code into nonsensical running code instead of rejecting it. Compiler malfunctions of type (a) are called “code generation defects”, whereas for type (b) the term “missing diagnostic defect” is used.
All compilers have defects, really, all of them, so this hazard applies to everybody. What is not obvious at all is whether the code in your project is affected by one or more compiler defects and what the consequences may be.
Browsing the lists of known bugs of open-source compilers and the release notes of the compiler you are using now, can give you an idea of how serious the problem is. Even then, you will only see a subset of the defects. Modern compilers have dozens to hundreds of compilation options and a defect can manifest itself on only a few of a virtually infinite number of possible option combinations and source code conditions.
Sometimes the compiler vendor itself issues defect notifications, but most compiler defects are found in the field by compiler users. In fact, it is not so uncommon for developers and engineers to come across these compiler defects while running everyday activities, when they notice suspicious behaviors in a program for instance.
Avoiding losses, project delays…and worse!
Once you are aware of the compiler defects, you need to work out exactly whether and how the compiler defect will affect your software project. Failure to do so may cause losses in any industry sector. For example, compiler defects may delay your project significantly.
For safety-critical software projects, compiler defects are potentially extremely dangerous and can cause personal injury or worse: they certainly cannot be ignored. Safety-critical project owners must:
- validate their compiler for their particular use case (i.e., set of compilation options) in their environment.
- analyze the potential consequences and check the code base to see if it is affected.
The question is: exactly which are the defects and what are the consequences for my project?
Answering the first part of the question is the purpose of compiler qualification. This is usually done by validation. That is by running a huge quantity of well-designed tests through the compiler, with the given set of options and in the intended operational environment, then checking the outcome of each test. Answering the second part of the question requires analyzing the project source code to detect the conditions triggering the compiler defects identified during compiler qualification.
Doing these checks manually is hugely expensive, inefficient and error prone. That’s why we have partnered with Solid Sands to develop an Application Hazard Scanner as part of their Compiler Qualification Service.
They chose to base their Application Hazard Scanner on our ECLAIR static analyzer because they know it is a robust and reliable platform. The Application Hazard Scanner automatically verifies that your software is not affected by any of the compiler defects identified during the qualification process.
This enables you to either prove that a code base does not trigger the conditions of given compiler defects, or to accurately identify parts of the source code that do trigger the conditions of given compiler defects. Of course, once you have deployed the Application Hazard Scanner, you can repeat the check any number of times during development, at no extra cost, and be immediately notified should your code base evolve in a way that triggers any compiler defects. This may save you significant time and resources, compared with the situation where the problem is identified only during the testing phase.
Delve deeper watching this webinar
Here’s how it might work in practice
Let’s say you find a compiler code-generation defect during the compiler qualification process. The compiler experts at Solid Sands investigate the defect and come up with a specification of the conditions triggering the defect. Then, BUGSENG static analysis experts turn that specification into an automatic checker and ship a corresponding ECLAIR plug-in to you. The ECLAIR package that hosts the plug-in already supports the MISRA C and/or MISRA C++ coding standards and mitigates all compiler missing-diagnostics defects.
If you’d like to see for yourself exactly how ECLAIR can help you with compiler defects you can contact us here.
Join our LinkedIn community to keep up to date with all our news.
Roberto Bagnara, PhD 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.