To get a trial key
fill out the form below
Team License (a basic version)
Enterprise License (an extended version)
* By clicking this button you agree to our Privacy Policy statement

Request our prices
New License
License Renewal
--Select currency--
* By clicking this button you agree to our Privacy Policy statement

Free PVS-Studio license for Microsoft MVP specialists
* By clicking this button you agree to our Privacy Policy statement

To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

I am interested to try it on the platforms:
* By clicking this button you agree to our Privacy Policy statement

Message submitted.

Your message has been sent. We will email you at

If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

Static and Dynamic Code Analysis

Static and Dynamic Code Analysis

Apr 13 2014

As a PVS-Studio's developer, I am often asked to implement various new diagnostics in our tool. Many of these requests are based on users' experience of working with dynamic code analyzers, for example Valgrind. Unfortunately, it is usually impossible or hardly possible for us to implement such diagnostics. In this article, I'm going to explain briefly why static code analyzers cannot do what dynamic analyzers can and vice versa. Each of these analysis methodologies has its own pros and cons; and one cannot replace the other, but they do complement each other very well.

Static code analysis is the process of detecting errors and defects in software's source code. Static analysis can be viewed as an automated code review process.

Dynamic code analysis is the method of analyzing an application while it is running.

I often come across similar suggestions by users that can be formulated as follows:

Your tool is wonderful. But it can't detect certain errors. For example, Valgrind has recently found this or that bug while PVS-Studio kept silent about it. I wish you added diagnostics for this and that type of bugs into PVS-Studio. Then I could do with just one tool and that would be very convenient.

Sure, it would be much more convenient and easy to work with one tool only. But, unfortunately, static analyzers cannot perform many types of analysis dynamic analyzers are capable of. It doesn't mean that static analysis is worse; it's just that these are two different technologies that complement each other. Now I will try to explain the limitations of both.

Suppose you have a function like this:

void OutstandingIssue(const char *strCount)
  unsigned nCount;
  sscanf_s(strCount, "%u", &nCount);
  int array[10];
  memset(array, 0, nCount * sizeof(int));

A static code analyzer cannot figure out whether or not an array overrun may occur here. If the string to be converted into a number is read from a file, this error is just impossible.

Well, reading a string from a file is a borderline case, so let's make the task a bit simpler. Suppose a string is formed somewhere in another function. Then the analysis is theoretically possible. In practice, however, it is enormously difficult: you need to find out the code execution sequence, which values the variables can take, what data will be written into buffers in memory, and if an array overrun is possible.

I've mentioned the case when data are stored in a string to show you how hard a static analyzer's job is. And there are many other difficulties it has to face when carrying out analysis. The later a value is used after it was calculated, the more work it takes to analyze this situation. When the fragment where a string is formed is separated from the fragment where it is used by several function calls, I can't even imagine how complex the analyzer should be and how much memory it will need to handle this task. The number of all the possible states and variable values is growing immensely fast. To find an error like that, you will need in fact to execute the program virtually - with all the possible branches covered. It is a very complicated algorithmic task which will also need enormous computational resources which are simply impossible to provide.

The important thing is, you just don't have to fight all these difficulties! What static analysis finds incredibly hard to do is just a piece of cake for dynamic analysis. A dynamic analyzer detects when a marker is deleted after an array, which indicates an array overrun.

Moreover, a dynamic analyzer can detect this error even when a string is read from a file!

Does it mean the dynamic analysis technology is better? Perhaps we just need to improve it a bit so that dynamic analyzers can do the job of static analyzers too?

And the answer is again - no, we can't do that; it's just impossible. Some tasks can be easily solved by static analysis but can't be solved by dynamic analysis.

Static analysis works with the source code of a program and can notice anomalies which don't exist for a dynamic analyzer. Let's discuss one example.

The code fragment below is flawless from the viewpoint of a dynamic analyzer. This code compares a part of a buffer - nothing to worry at. It's a very frequent situation when the memcmp() function compares not the entire buffer, but only a part of it; and it happens very often that you need to use only a part of a buffer. A dynamic analyzer has nothing to be angry with in this code.

But a static analyzer examines the code and figures out that the number of bytes being compared is very likely to have been incorrectly calculated. This sample was taken from a real open source project:

const unsigned char stopSgn[2] = {0x04, 0x66};
if (memcmp(stopSgn, answer, sizeof(stopSgn) != 0))

The error is about a parenthesis put in a wrong place. A static analyzer can detect this anomaly quick and easy and inform the user about it. From the viewpoint of dynamic analysis, everything's alright here: one byte is being compared - so what? Comparing just one byte is a common situation, especially in macros.

Conclusion. We have discussed two types of errors each of which can be detected by only one of the two code analyzers, this limitation determined by their fundamental working principles. So, however pitiful it is, we can't do with one type of tools only. The best result can be achieved only when using both static and dynamic analysis together.


Popular related articles
PVS-Studio for Java

Date: Jan 17 2019

Author: Andrey Karpov

In the seventh version of the PVS-Studio static analyzer, we added support of the Java language. It's time for a brief story of how we've started making support of the Java language, how far we've co…
The Ultimate Question of Programming, Refactoring, and Everything

Date: Apr 14 2016

Author: Andrey Karpov

Yes, you've guessed correctly - the answer is "42". In this article you will find 42 recommendations about coding in C++ that can help a programmer avoid a lot of errors, save time and effort. The au…
Free PVS-Studio for those who develops open source projects

Date: Dec 22 2018

Author: Andrey Karpov

On the New 2019 year's eve, a PVS-Studio team decided to make a nice gift for all contributors of open-source projects hosted on GitHub, GitLab or Bitbucket. They are given free usage of PVS-Studio s…
Characteristics of PVS-Studio Analyzer by the Example of EFL Core Libraries, 10-15% of False Positives

Date: Jul 31 2017

Author: Andrey Karpov

After I wrote quite a big article about the analysis of the Tizen OS code, I received a large number of questions concerning the percentage of false positives and the density of errors (how many erro…
Appreciate Static Code Analysis!

Date: Oct 16 2017

Author: Andrey Karpov

I am really astonished by the capabilities of static code analysis even though I am one of the developers of PVS-Studio analyzer myself. The tool surprised me the other day as it turned out to be sma…
The Evil within the Comparison Functions

Date: May 19 2017

Author: Andrey Karpov

Perhaps, readers remember my article titled "Last line effect". It describes a pattern I've once noticed: in most cases programmers make an error in the last line of similar text blocks. Now I want t…
Static analysis as part of the development process in Unreal Engine

Date: Jun 27 2017

Author: Andrey Karpov

Unreal Engine continues to develop as new code is added and previously written code is changed. What is the inevitable consequence of ongoing development in a project? The emergence of new bugs in th…
How PVS-Studio Proved to Be More Attentive Than Three and a Half Programmers

Date: Oct 22 2018

Author: Andrey Karpov

Just like other static analyzers, PVS-Studio often produces false positives. What you are about to read is a short story where I'll tell you how PVS-Studio proved, just one more time, to be more atte…
Technologies used in the PVS-Studio code analyzer for finding bugs and potential vulnerabilities

Date: Nov 21 2018

Author: Andrey Karpov

A brief description of technologies used in the PVS-Studio tool, which let us effectively detect a large number of error patterns and potential vulnerabilities. The article describes the implementati…
The Last Line Effect

Date: May 31 2014

Author: Andrey Karpov

I have studied many errors caused by the use of the Copy-Paste method, and can assure you that programmers most often tend to make mistakes in the last fragment of a homogeneous code block. I have ne…

Comments (0)

Next comments
This website uses cookies and other technology to provide you a more personalized experience. By continuing the view of our web-pages you accept the terms of using these files. If you don't want your personal data to be processed, please, leave this site.
Learn More →