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.

How PVS-Studio Proved to Be More Attent…

How PVS-Studio Proved to Be More Attentive Than Three and a Half Programmers

Oct 22 2018

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 attentive than several people.


A guy sent an email to our support saying that the analyzer was producing four false positives at once on one line of his code. The email initially got into Evgeny Ryzhkov's email box. He glanced through the feedback, found nothing strange and forwarded it to our leading developer Svyatoslav Razmyslov. Since Evgeny didn't really examine the code, he counts as just half a programmer :).

Svyatoslav read the email and didn't believe the analyzer could be so wrong. So he came to me and asked for help. He hoped I had a better eye for such things and could notice something to help us find out the reason why the analyzer had issued all those strange messages. Sadly, I could only admit that they were strange indeed and shouldn't have been there. Yet I still had no idea about the cause. So we opened a task in the bug tracker to track it down.

It was not until Svyatoslav started making up synthetic tests to describe the problem in detail in the bug tracker that he had the "Aha!" moment. Now, let's see if you guys can quickly spot the defect that triggered those four messages.

Here's the email text (published with the author's permission) along with the attached image illustrating the problem.

V560 warnings here are all false. Running with most recent version of PVS-Studio for personal use. Basically, "IF" statement is correct. Outer one is done for speed - inner ones are still needed and non are always true or false.


Click on the image to enlarge.

Now guys, it's time to test yourselves! Can you see the bug?

Don't hurry, look carefully. And the unicorn will just sit here and wait.


With that introduction, I bet it didn't take you much time to spot the bug. When you are determined to find one, it comes up quickly. But it's way harder to notice it after reading an email that calls it "false positives" :).

Now let me explain it to those who were too lazy to bother trying. Look at the condition once again:

if (!((ch >= 0x0FF10) && (ch <= 0x0FF19)) ||
     ((ch >= 0x0FF21) && (ch <= 0x0FF3A)) ||
     ((ch >= 0x0FF41) && (ch <= 0x0FF5A)))

The programmer intended to check that the character didn't fall into any of the three ranges.

The error here is that the logical NOT (!) operator is applied only to the first subexpression.

If this condition is true:

!((ch >= 0x0FF10) && (ch <= 0x0FF19))

then further evaluation of the expression is aborted, just as prescribed by the short-circuit evaluation semantics. If the condition is false, then the value of the ch variable lies in the range [0xFF10..0xFF19] and the next four comparisons make no sense since they will all be either true or false.

So, once again, just to make it clear: if ch is within the range [0xFF10..0xFF19] and the evaluation continues, then:

  • ch >= 0x0FF21 is always false
  • ch <= 0x0FF3A is always true
  • ch >= 0x0FF41 is always false
  • ch <= 0x0FF5A is always true

That's what PVS-Studio is telling us.

That's it. The static analyzer proved to be more attentive than one user and two and a half programmers from our team.

To fix the bug, we just need to write additional parentheses:

if (!(((ch >= 0x0FF10) && (ch <= 0x0FF19)) ||
      ((ch >= 0x0FF21) && (ch <= 0x0FF3A)) ||
      ((ch >= 0x0FF41) && (ch <= 0x0FF5A))))

Or rewrite the condition:

if (((ch < 0x0FF10) || (ch > 0x0FF19)) &&
    ((ch < 0x0FF21) || (ch > 0x0FF3A)) &&
    ((ch < 0x0FF41) || (ch > 0x0FF5A)))

Actually, I wouldn't recommend either of these solutions. Personally, I'd make the code clearer by writing it as follows:

const bool isLetterOrDigit =    (ch >= 0x0FF10 && ch <= 0x0FF19)  // 0..9
                             || (ch >= 0x0FF21 && ch <= 0x0FF3A)  // A..Z
                             || (ch >= 0x0FF41 && ch <= 0x0FF5A); // a..z
if (!isLetterOrDigit)

Note how I removed some of the parentheses. As you just saw, adding a bunch of parentheses doesn't help prevent an error. Parentheses are meant to make code easier to read, not to obscure it. Programmers remember very well that the precedence of the comparison operations =< and => is higher than that of the && operator. That's why you don't need parentheses to handle them. But if you ask which operator - && or || - has higher precedence, many will be confused. That's why it's better to add parentheses to define the order of evaluation of && and || just to be sure.

The question why it is better to write || at the beginning was addressed in my article "The Ultimate Question of Programming, Refactoring, and Everything" (see the chapter "Table-style formatting").

Thanks for reading. Come over to our website to download PVS-Studio and give it a try. It'll help you catch lots of bugs and potential vulnerabilities at the earliest development stages.

Popular related articles
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…
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…
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…
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 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…
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…
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 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…
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 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…

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 →