Static Analysis? We Don’t Need No Stinkin’ Static Analysis

Of course, the original quote is from the 1948 movie, The Treasure of Sierra Madre, and has been famously parodied over the years, memorably in the comedy classic Blazing Saddles. But we are not here to talk about badges. We are here to talk about static analysis and C and C++ programmers.

I am talking specifically to C and C++ programmers because they tend to be in the majority when it comes to embedded applications but the discussion is equally applicable to most other programming languages in common use including Java.

C programmers are really the target for this article because C lacks almost any static analysis short of enough for the compiler to turn the source code into object code. C has been touted as a high level macro assembler and that is not too far from the truth. Its advantage is how close it allows a developer to get to the hardware. The downside is that the developer must create an application that is error free based on their expertise. Most programmers want to think they are good and conscientious but expertise varies widely. The problem is that even the best programmers make mistakes and these can be hard to find and correct.

C++ has many of the problems of C but significant improvements in other areas including a better type and template system that does significantly more static analysis that can help catch errors early. The problem is that C++ essentially allows the same issues to arise that occur in C. For example,

            if ( i == 10 ) {}

does not do the same thing as

            if ( i = 10 ) {}

The latter is an assignment that is always results in a true condition. Some C and C++ compilers do a little more static analysis and will flag this as an error or warning even though it is a valid statement.

Coding standards typically catch this class of error, especially those that implement all or part of the standards using static analysis tools. In the simplest case it is a matter of enabling this checking by the compiler. Even using this minimal static analysis support can be very beneficial.

So why do programmers forego static analysis?

In our recent Embedded Revolution survey, we did ask about the importance and use of coding standards and static analysis (see figure below), but not why. Less than half of those in the survey even had a standard to follow let alone using a static analysis tool that enforced the process.

Not all companies are employing coding standards in their development process. Multiple responses were possible so only some of the 43 percent employed MISRA C/C++ (from Electronic Design’s 2017 Embedded Revolution survey).

 

At this point I have to theorize why this is the case and I think it comes back to the “We don’t need no stinkin’ badges” quote. Programmers and managers like to think they are better at preventing bugs from creeping into their code and that any limitations or tools that would “get in the way” are bad. Never mind that these tools or procedures would catch or eliminate a significant number of bugs in the long run that gives more time to find those other bugs that are in the code or to spend time improving and application, or getting the application done sooner, or …

Another issue is availability of open-source tools. The LLVM Clang Static Analyzer is one option. It works with C, C++, and Objective-C as a standalone application. CPPcheck is another open-source option. It is integrated with a number of development tools including Eclipse, Visual Studio, and there is even a Git-plugin for catching errors in files as they are committed. There is a list of CPPcheck checks available.

There have also been a number of projects to add annotations to address programming issues, although none tend to be as integrated or exhaustive as SPARK. One example is the Clang thread safety annotation. The following example shows some of the annotations and where an error would occur.

       

 

In this case the function foo uses variables a and b. The first is protected by mutex mu1 and the other by mu2. Unfortunately on the mu1, mutex is locked.

Often these tools cover certain aspects of static analysis such as looking for style issues or particular types of bugs. Using multiple tools can be more cumbersome but they provide better coverage of potential problems. Many commercial tools address a wider range of issues and often have better reporting features.

As many would say, “There Ain’t No Such Thing as A Free Lunch” (TANSTAFL). Developing coding standards, implementing them, using static analysis or using programming languages like Rust and SPARK/Ada is not free from costs. The real question is whether the cost of using these techniques or tools provides a sufficient payback. In general, they do pay and usually quite well, although your mileage may vary.

It is always hard to get workers of any sort to switch to different techniques when the current ones have been working, to a degree. It is also a hard sell for those delivering the tools because of this. The losers when these tools and techniques are not used are across the board though as applications get shipped with bugs and security holes that come back to haunt not only the consumer but the company and its employees.

 

from Electronic Design - Engineering Essentials Curated By Experts http://bit.ly/2pmGKkI