Static Analyzer
The term static analysis generally refers to external tools that can be used alongside a compiler or build system.
Static Analysis in Compilers?
A method of computer program debugging that is done by examining code without executing the program.
The process provides an understanding of the code structure and can help ensure that the code adheres to industry standards.
This might lead to false positives where the tool reports problems with the program that do not actually exist. Fuzzing in combination with dynamic program analysis can be used to try to generate an input that actually witnesses the reported problem.
Relationship to compiler…
From: What’s the relationship between Compilers, static analysis and dynamic analysis Static analysis reasons about the code without running it. The goal is to tell you something about the code. For instance, it is possible to catch many errors by using a tool to analyze the code. They are amazingly powerful. Many C and C++ static analyzers can tell you about common memory management errors like buffer overflows, double frees, and null references just by reasoning about it. They also perform security analysis, performance analysis, and so forth. The complete feature set depends on the tool. One of my favourite ones is taint analyzers. Any variable that accepts user input is considered tainted until proper validation is done on it. And anything that touches tainted variables becomes tainted. And if the tainted variables ever touch something like SQL, you have a SQL injection waiting to happen.
Now, to talk about the relationship. Many compilers perform static analysis in order to improve the quality of the output code. For instance, it is trivial to detect that a variable is never used. So a compiler will just drop it and not bother. It saves you compute time and memory. Others are more complex (loop optimizers for instance). Any time you hear anything about compiler optimizations, people are actually talking about static analysis that is used to inform code generation. But compiler optimizers are intentionally limited. They don’t have global awareness, and they need to ensure correctness. So they are conservative. Usually, when someone talks about static analyzers, they are talking about something that runs independent of the compiler.
Now static analyzers have one big problem. Namely, the halting problem. They can never catch all the problems or model everything. It is mathematically impossible. Dynamic analyzers run the program inside them. They examine what is going on, what happens, and so forth. A very common use is to check for memory leaks, deadlocks, and race conditions. So dynamic analyzers check for the things that static analyzers cannot by actually running the code.
Static vs Dynamic Analysis
Static analysis is a kind of semantic analysis whereby the source code is analyzed at compile time. If you can look at your code and see ways to improve it from 15 lines to 5 lines, and with improved performance, then that is a pattern that may be optimized by static analysis.
Dynamic analysis is a kind of semantic analysis whereby the bytecode is analyzed at runtime. This is synonymous to Just-in-time (JIT) compiling, which is a feature of many of modern virtual machines. The JIT may be triggered, for example, whenever an if-statement inside a loop has a condition variable that will not change within the scope of the loop. It will then keep the branch of the if-statement that evaluates to true and delete the rest. This will help reduce performance bottlenecks since no extra CPU cycles are being wasted by reevaluating the if-statement.