Misconception: Static Analysis Is Only About Finding Bugs

By Ram Cherukuri, Jeff Chapple, Stefan David, and Jay Abraham

Faster time-to-market trends could possibly be driving the misconception that static analysis is only about finding bugs. Software developers must eliminate as many bugs as possible and will use a quick bug finding tool, though it is likely that some bugs will remain. This practice may be sufficient for non safety-critical applications such as smartphone apps, but it may be insufficient for safety-critical applications. Safety-critical applications, therefore, require more rigorous methods to verify safety and robustness, which is where the other benefits of static analysis come in. In this article we will bust the misconception that static analysis is only about finding bugs, and prove that it can help verify compliance to coding standards, produce metrics about code quality, and be used at any stage of software development.

Finding bugs is definitely one important aspect of static code analysis. However, static analysis techniques can range from simple syntax checking or heuristics-based approaches to advanced formal-methods based verification. This range also represents the wide variety of the static analysis tools on the market. For example, some advanced compilers have a built-in syntactic checker as a form of static analysis. At the other end of the spectrum are formal-methods based tools like Polyspace® products that do semantic analysis to give you detailed run-time behavior of your software.

For example, Polyspace Bug Finder™ is a static analysis tool that helps you find bugs, but it can also be used to (1) check your software compliance to coding standards such as MISRA C/C++, JSF++, and custom rules, and (2) produce code metrics to help improve code quality. In addition, with Polyspace Code Prover™ you can prove that your software will not crash due to certain types of critical run-time errors.

Therefore, these tools go beyond simple bug finding, and are valuable in the verification and validation process. For example, the code in the image below is the result of formal verification that confirms an overflow can never occur under any operating conditions:

Result of formal verification that confirms an overflow can never occur under any operating conditions.

As mentioned before, you can use static analysis to check if your code complies with particular coding guidelines or standards, thus preventing the use of unsafe or unreliable constructs. It can also help you capture key metrics that are indicative of code quality such as cyclomatic complexity, unreachable code, use of shared global variables, and recursions - without the overhead of writing test cases. These metrics could help you identify design issues such as the architecture of your code that can ultimately impact the performance and the reliability of the software.

For example, use of non-initialized variables or unprotected shared variables could show up as an unexpected result in a particular test case. You might then embark on a debugging mission and spend countless hours trying to identify the problem. Even more troubling is the fact that these defects may not show up during testing because of the unpredictable nature of such run-time errors.

The broader benefits of static analysis are not as well known, and so it is adopted in late stages of software development workflows. Because it is perceived simply as a way to find bugs, it is usually adopted in the final stages of software development (e.g., static analysis is the last gate before the code is released by the QE group). More than 90% of the potential customers who contact us about our static analysis solution are entering the end phase of a project.

However, if you want to leverage all of the benefits discussed above, you should incorporate static analysis in the earliest stages of development. In fact, the use of a compiler is an example of this, because a compiler is a very simple static analysis tool that helps develop the syntax and the semantics of the code. Studies highlight the significant cost benefits in finding and fixing coding errors early*. You also decrease the amount of required testing for the software you’re developing. In this way, static analysis is important to incorporate into your workflows early, and it goes way beyond simply identifying bugs.