Actually, a better question for many embedded developers is whether they’re using even one code analysis tool. In many cases, the number of static or dynamic analysis tools used by a programmer is zero. At the same time, the goal that seems to be on top of everyone’s list is getting bug-free software done on time. Unfortunately, this can be a challenge when you aren’t using these tools.
Most developers know that finding and fixing bugs early is less costly by orders of magnitude as code moves progressively away from its creator. The cost in time and money of fixing a bug found only a week later is significantly higher than one found the same day that the code was written or modified. The cost gets progressively higher as it moves through Q&A and out into the field. In many cases, especially for embedded devices, the cost of fixing deployed products isn’t even considered unless liability concerns mandate a fix.
Still, getting programmers and managers to utilize static and dynamic analysis tools is a challenge. I ran into a similar problem almost 20 years ago working at NuMega Technologies on a tool called BoundsChecker. It is now part of Compuware’s DevPartner for Visual C++ Bounds- Checker, but it started as a tool to check the parameters passed to the Windows operating system.
Even then, Windows had a massive number of interfaces associated with it, and there was little error checking on the operating-system side. Passing a negative number where a pointer was required could often result in a system crash, so it pays to pass parameters that are expected. Unfortunately, you run into an array of myths while selling a tool like BoundsChecker, from “I don’t make those kinds of mistakes” to “It generates false positives.”
These myths persist today even though the tools are more robust and varied. In fact, those in the know often use more than one tool, and analysis tool suites frequently include a range of static and dynamic analysis tools (see “The Latest Static And Dynamic Code Analysis Tools”).
Part of the issue is understanding what each tool does and how it works. These tools typically check hundreds or thousands of cases and conditions. The goal is the same bug-free code. Unfortunately, this means finding or preventing bugs. Many designers miss this distinction.
That’s why tools like LDRA Software Technology’s TBvision may provide recommendations as in this case with MISRA C++, an automotive coding standard (see the figure). But MISRA C/C++ is just the tip of the iceberg. Other static analysis tools, including TBvision, can identify errors statically in addition to handling coding standards.
The kinds of errors found by static or dynamic analysis by different tools sometimes overlaps, but often they address different areas. This is why using more than one tool can be more helpful. Of course, using one to start with is a good first step.
Reprints
