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.

A User's Experience of Working with the…

A User's Experience of Working with the Analyzer

Oct 25 2013

When the PVS-Studio team announced that they had finally released a standalone version which didn't require you to have Visual Studio installed to be able to work with it, I certainly couldn't but try it :) Before that I already had experimented with the trial version on one of our old projects. And now I got a chance to check the code of our recent project built in the AVR Studio IDE (it's eclipse-based).

Analysis based on pre-generated preprocessed files is no longer supported. Please consider using the Compiler Monitoring mode instead. This mode allows a generation and analysis of preprocessed files automatically during regular build process.

This text is a copy of a post by one PVS-Studio user, originally published in Russian here. It was kind of Alexander to permit us to publish it at our website and translate it into English.

To be able to work with the analyzer, you need special files generated by the preprocessor. The AVR environment can do that, but there's one subtle nuance: when you turn on the flag "Preprocessor only" you really get the preprocessed files - but they still have the .o extension instead of the .i you expected. Well, it took me 5 minutes to write a Python script to solve this small problem, and here we go - the analyzer runs well!

I was quite surprised to get very few messages - just about a couple of dozens. Most of them were insignificant warnings or false positives (one and the same value is written twice in a row into the register in embedded, and the analyzer considers it a potential error (and I agree with it on this point - you'd always better play safe and check such places to be sure)).

In a few fragments real misprints and copy-paste mistakes were found. For example, a variable of one enum is compared to a value of another enum. Or, one and the same variable is assigned two different values in a row (however, as I said before, it was in most cases false positives triggered by writing sequences into the register).

But it was the only message that I found most interesting and which made me write this post: "Possible NULL pointer dereferencing"...

It happened so that all throughout the code we used a construct of this kind:

void fun(error_t * perr)
 *perr = SUCCESS;
 if (something)
    *perr = SOME_ERROR;

And just in a few functions it was a bit different:

void init(void)
  error_t err = SUCCESS;

And one day, after a small refactoring, we got the following code in one fragment:

void some_init(void)
  error_t *perr = SUCCESS;

It was this particular line that the analyzer was angry with. SUCCESS was 0, of course.

Let's now rewind the time a bit - to the place when this change was brought into the repository.

A pretty large suite of automatic tests continued to be passed successfully after the refactoring. Code review failed discover the problem in that line (we've got too many lines *perr = SUCCESS in the code, so it was no wonder we missed that particular one).

About 30 days later after that commit the night tests crashed for the first time. We failed to reproduce the crash.

Then they crashed again. And again. We found out experimentally that the crash occurred once per thirty runs of the test suite on the average.

Our team spent about 50 hours to track the bug. All in vain. Well, we actually managed to locate the commit after which we started having troubles - but we never revealed the reason for crashes itself.

By the way, it was lying two steps lower. The function some_fun(perr) contained a call of some_other_fun(perr) which, in its turn, called some_third_fun(perr). And this last function had a code checking for errors:

  if (*perr != SUCCESS)

That is, despite that no errors occurred in the function some_action (which was quite uncommon, as it made use of a whole lot of external periphery, because of which we had troubles trying to locate the problem), whether or not the loop continued depended on the value stored at the 0 address (in embedded a zero address is legal in most cases). And in most cases we had 0 written at this address.

The conclusion is: the bug we had wasted about 50 hours to track was detected at once with the first run of the analyzer and fixed in less than an hour!

A convincing argument to start using the analyzer, isn't it? Alas, not always. In particular, ours was that very case when it is not so: since we get paid for the project on the time and material scheme and those 50 hours were paid for by the customer, integration of the analyzer implies real direct damages for our administration :(((

And one more thing: the project employs FreeRTOS - and you know, we got not a single warning on it during the check!

And yes, this post was written solely from my love to analyzers.

Note by PVS-Studio developers.

Thank you for your post. We were pleasantly surprised by it: first, because you've described a positive experience; second, because you managed to cope with an AVR Studio project, though we didn't adapt the analyzer to that IDE in any way.

By the way, this article shows a good example of how one should not use a static analyzer. If one used it regularly (see incremental analysis), an error like the described one and perhaps many of plainer bugs would have never occurred. This is not the case, of course (we don't have a plugin for AVR Studio currently), but this is a thing to keep in mind for those who use Visual Studio or Embarcadero RAD Studio.

Thanks again for the article.


Popular related articles
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…
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…
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…
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…
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…
The way static analyzers fight against false positives, and why they do it

Date: Mar 20 2017

Author: Andrey Karpov

In my previous article I wrote that I don't like the approach of evaluating the efficiency of static analyzers with the help of synthetic tests. In that article, I give the example of a code fragment…
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…
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…
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…
PVS-Studio ROI

Date: Jan 30 2019

Author: Andrey Karpov

Occasionally, we're asked a question, what monetary value the company will receive from using PVS-Studio. We decided to draw up a response in the form of an article and provide tables, which will sho…

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 →