Static code Analyzer

Developers often discover issues during QA testing, CI/CD failures, Product deployment. Even though many of these issue are often detectable at earlier stages of development. Most of the bugs in production are not caused by some complex algorithm or some obscure edge case, common issues faced in products are null value dereferencing, memory leak, unused code, unreachable code etc.

What's interesting is a many of this issue can be address even before the program ran. Today, we have tools that can analyze source code and flag such problems early in development. Yet, many developers either remain unaware of them or do not proactively integrate them into their workflow.

These tools are called Static Code Analyzers. And contrary to what some might assume, not all of them are expensive. Tools like Cppcheck and Clang Static Analyzer are open-source and freely available, and we all can start taking benefit of such tools even in our daily coding practice.

Static Code Analysis involves the examination of source code without its execution. This analysis is performed in the code’s static state, typically during the development phase or in a pre-deployment environment. SCA tools scrutinize the code for potential vulnerabilities, adherence to coding standards and general software quality issues without the need for actual execution. It offers a proactive means to identify and rectify issues early in the development life cycle.

#include <array>
int main()
{
        std::array<int,5> arr;
        for(int index=0;index<= arr.size(); index++)
        {
                arr[index]=index;
        }
        return 0;
}        

At first glance the code looks appears correct and can compile error. However, there is a subtle issue in the loop condition. The static analyzer tool can detect such out of bound access issues in development stage itself.

How Static Analyzer work under the hood?

Perquisite: understating of how source code is compiled.

Some of the static analyzer tool use the Abstract syntax tree generated during the compilation stage or it can also have internal implementation of tools for AST generation.

Why Static Analyzers Catch Bugs Compilers Miss?

One might wonder, if both compiler and a static analyzer goes through same stages of code processing and AST generation why don't the compiler itself perform these static code check. Wouldn't that solve a lot issue as we can identify lot of errors in compilation stage itself.

Both compilers and static analyzers build similar internal structures, but they use them for different purposes. A compiler mainly checks whether the code is valid according to the language rules. If code is syntactically and semantically valid, so the compiler allows it.

Where as incase of Advanced analysis like path-sensitive analysis requires exploring multiple possible program paths.

 if(flag) 
    ptr = new int; 

 *ptr = 10;        

In cases like this the analyzer must evaluate both possibilities:

• flag == true
• flag == false

For large programs this can become very expensive. Compilers prioritize fast compilation, so they avoid this heavy analysis.

Many static analysis problems relate to the famous concept in computer science called the Halting Problem. It states that it is impossible to perfectly determine whether every program will terminate or behave correctly.

Because of this limitation:

• static analyzers may produce false positives.
• compilers avoid doing overly aggressive analysis.

In upcoming articles we can take deeper dive in understanding Cppcheck and Clang static sanitizer tools.