What Is Differential Analysis?
Static analysis results can help ensure that your code is free from costly security vulnerabilities and coding errors. However, it can be difficult to efficiently run an accurate pre-commit static code analysis of your codebase when codebases are large, due to the sheer size of the computational task. Differential Analysis offers a solution.
As Klocwork is one of the very few static code analyzers capable of Differential Analysis, we have provided an explanation of what is Differential Analysis, how Differential Analysis works, and some specific Differential Analysis examples.
What Is Differential Analysis?
Differential Analysis is a form of “fast feedback” static code analysis that uses system context data from previous analysis builds to analyze only the new and changed files while still providing results as if the entire system had been analyzed. This approach provides the shortest possible analysis times for the new and changed code while maintaining the accuracy and detail of the analysis data.
Differential Analysis is an extension and improvement over more traditional Incremental Analysis techniques, as it requires no prior analysis build of the software on your workstation. This also makes Differential Analysis well suited for DevOps CI/CD Pipelines where each job uses a new machine instance or container.
How Does Differential Analysis Differ from Incremental Analysis?
When you write code, most likely you will want to check the impacts of your changes on the quality, security, or standards compliance of your codebase. In general, this involves running a local or pre-commit analysis of your code.
If this is not done and the code is already committed when the analysis is performed, you may have already have moved on to another task and fixing those issues could be pushed back further — potentially as far as the final release cycle when the backlog of open issues is then presented to the development team.
With control and data-flow static analysis tools, this local or pre-commit analysis will generally involve running an analysis of the entire codebase — complete with changes — and reporting back the new issues.
This works perfectly well for smaller projects, but issues arise when dealing with larger codebases and longer analysis times.
To keep analysis times appropriate for local or pre-commit analysis, static analysis tools often provide some form of Incremental Analysis capability.
This means that a code change does not require a new analysis build of the entire system but, instead, just an analysis of the changed files and any files with dependencies upon them.
However, that can still be inefficient. In a worst-case, analyzing the dependencies is similar to analyzing your entire codebase, which — depending on the project — can range from a few minutes to several hours.
In addition, traditional Incremental Analysis also requires that there has been at least one prior build of the entire codebase on your workstation, which — again, depending on the project — may not even be possible.
Differential Analysis solves that problem.
How Does Differential Analysis Work? Examples of Differential Analysis
Klocwork’s Differential Analysis works automatically when a local desktop project workspace is connected to a server project.
Each time you run a Klocwork integration analysis and push those results to the Klocwork server, they’re saved, and details of the interface behaviors of the existing codebase are then made available for the client tools.
Then each time you run an analysis from your Klocwork desktop or CI tools, this interface behavior information is then the baseline for the rest of the system context.
When performing Differential Analysis of changed code, if Klocwork detects a call to another function or method that hasn’t changed, and therefore has not also been analyzed locally, the interface behaviors from the central server data are used to inform the analysis of your code instead.
To better illustrate that process, here are some examples of Differential Analysis.
The null pointer initialized on line 11 will be passed through the calls on line 14 and 21 into sendMessage(..), where it will be swiftly dereferenced and cause this program to crash. If you were to use one of Klocwork’s desktop tools — the command-line kwcheck tool or the Klocwork Desktop GUI to analyze just main.c — you wouldn’t see any defects:
But, let’s say that you’ve got an integration build analysis checked into a project on your Klocwork server. If you were to connect your local project to that project and then re-analyze main.c, you would be able to see the defect:
However, the traceback doesn’t show detail from sendMessage(..) because it hasn’t been analyzed locally, but the knowledge base on the server does show that sendMessage(..) dereferences the 3rd argument passed to it.
With this, you should have enough information now to fix the defect before you commit your code — all without having to analyze your entire code base.
But, what if you were to analyze the whole project at once? You would see the detail in the traceback about the sendMessage(..):
The knowledge base that’s on the server is based on the most recent analysis checked in there — this is likely the last analysis of your project’s main codebase.
However, the knowledge base records for certain functions may be different than the records that would result from analyzing the code within your own workspace.
This is beneficial as the code you’re committing will soon be merged into your mainline and the defects you see now will likely appear after that merge.
With differential analysis, you’re getting a preview of the defects you’ll get after merging, and a chance to fix them ahead of time.
Why Klocwork Is The Ideal Static Analysis Tool
In addition to Differential Analysis, Klocwork has other analysis and DevOps features that can enable you to:
- Ensure that complex software is secure, safe, and reliable.
- Reduce the cost of finding and fixing defects earlier in development.
- Prove compliance by enforcing software coding standards.
- Improve developer productivity, testing efforts, and velocity of software delivery.
- Report on quality over time and across product versions.