Finding problems in applications is not always an easy task. Finding and solving problems dynamically often involves implementing debuggers and trace utilities while trying to duplicate a symptom. Static analysis tools take another path by examining source code and trying to identify problems before the application is run.
Static analysis is a wide topic area and there are plenty of materials on the Internet for those new to the idea. This time around I took the opportunity to pose some questions to vendors and researchers in this space regarding their tools and experiences.
I started with some Q&A sessions with major vendors in this space including Grammatech and Klocwork. I may be adding a couple sources more as time goes by.
I also invited David Evans, Associate Professor of Computer Science, University of Virginia, into the fold for some feedback about Splint (click here for the interview). Splint is an open source project based on work that Evans managed. Splint is still available but not actively being developed because the grant money ran out (as it often does for many projects). Still, Splint is a power option available to programmers.
The Good, The Bad, And The Ugly
Most C programmers are probably familiar with lint, a static analysis tool that was primarily put together to check for common programming problems and to enforce style checks. The program is handy when working with a team to enforce common styles.
Most static analysis tools check the code against a set of rules. Some, like MISRA C, limit the user to a subset of the programming language, in this case C. This attempts to reduce the number of bugs in an application by enforcing good programming practices. Other analysis tools attempt to figure out the program's operation and see if the program is working properly with respect to other constraints.
Static analysis programs are not limited to C, though these are the most common. Likewise, programming problems that can be addressed can be quite varied. Often the tools can be customized to check for problems that are common in a particular programming environment.
For example, if a function is called with a constant then it is possible to determine if the constant is valid for the function. This check is performed at compile time (or when the tool is used since some are independent of the compiler) instead of runtime. As with most static analysis, the approach does not eliminate runtime checks but makes their exception detection occur much less often.
This particular example can be extended by checking variable assignments for variables used in the function call. The extent of this checking is dependent upon the tool but often they are much more ambitious than the simple example presented here.
Of course, as the problem with program analysis of this type is the possibility of generating false positives. These are warnings or errors from the tool's perspective but are actually desired operations by the programmer. An occasional false positive is not a problem, but a large percentage overall would tempt any designer to can the faulty tool.
Another issue is time. Tools that do a lot of analysis can take a lot of time. Luckily the development platforms today often have cycles to burn. Static analysis is also something that lends itself to multicore solutions since most analysis can be performed in parallel.
I have found static analysis tools to be useful but often time consuming. On the other hand, having a quad core system on my desk has been chancing a lot of my attitudes to development tools like static analysis and background builds.
I would be interested in hearing about your episodes with static analysis tools. There are quite a few companies that swear by them making them in their development cycle. This is especially true as static analysis tools move into other areas such as security. Yes, it is possible to check for security breaches and problems that can allow security problems to occur more often. But that is for another article.
Definitely check out the individual Q&As I’ll be posting soon. They’re sure to have more in-depth details.
Grammatech
www.grammatech.com
Klocwork
www.klocwork.com
Reprints
