Pour obtenir une clé
d'essai remplissez le formulaire ci-dessous
Demandez des tariffs
Nouvelle licence
Renouvellement de licence
--Sélectionnez la devise--
* En cliquant sur ce bouton, vous acceptez notre politique de confidentialité

Free PVS-Studio license for Microsoft MVP specialists
To get the licence for your open-source project, please fill out this form
** En cliquant sur ce bouton, vous acceptez notre politique de confidentialité.

I am interested to try it on the platforms:
** En cliquant sur ce bouton, vous acceptez notre politique de confidentialité.

Votre message a été envoyé.

Nous vous répondrons à

Si vous n'avez toujours pas reçu de réponse, vérifiez votre dossier
Spam/Junk et cliquez sur le bouton "Not Spam".
De cette façon, vous ne manquerez la réponse de notre équipe.

0,1,2, Freddy came for Blender

0,1,2, Freddy came for Blender

26 Oct 2022

This article could have been named "How PVS-Studio prevents rash code changes, example N7". However, naming articles like that becomes boring. So today Freddy Krueger's name is in the title, and you'll find out why.


We're all people, we all make mistakes. Especially when we are in a hurry. Programming is no exception for that. There's suddenly a light-bulb moment, and you rush to write the code while the thought is still clear in your head. Developers do know how hard it is to collect all the puzzle pieces in your head after getting distracted. I have a pic for that:


Sometimes developers are in a hurry when writing code. Besides, they also may miss something — especially when the code seems simple. I think that's how the error below occurred. And it wasn't noticed during code review — the code is so simple, there's nowhere to go wrong.

One of the Blender developers made a commit shown in the first picture of this article, and PVS-Studio found an error there. So, I decided to write another note about how the static analyzer helps fix errors in code. Providing, of course, if it's used :). I'm not writing about all errors, only about interesting ones.

Incorrect code:

static void initSnapSpatial(TransInfo *t, float r_snap[3],
                            float *r_snap_precision)
  /* Default values. */
  r_snap[0] = r_snap[1] = 1.0f;
  r_snap[1] = 0.0f;
  *r_snap_precision = 0.1f;

The PVS-Studio analyzer issued a warning: V519. The 'r_snap[1]' variable is assigned values twice successively. Perhaps this is a mistake. transform.c. Check lines: 1727, 1728.

The developer decided to fill an array with default values, but was in a rush. As a result of a typo, there are two errors at once:

  • The second element of an array (r_snap[1]) is initialized by an incorrect default value. The developer had to write 1.0f there, but wrote 0.0f;
  • The third array element (r_snap[2]) remains uninitialized by default. Then, another value may be written to this element of the array. If the value is not written, the element remains uninitialized, and that leads to undefined behavior.

So, what does Freddy have to do with it? The answer is simple: 0,1,2 attract many errors. I wrote an article about that — "Zero, one, two, Freddy's coming for you".


From the lyrics of this song we can assume that Freddy's coming for Blender.

How to avoid such errors?

  • Don't rush when writing code.
  • Thoroughly review the code — even if it seems simple/uninteresting.
  • Use PVS-Studio to search for errors.

You don't need to choose only one point. All three are important! Use them all together. Thank you and I wish you bugless code.

Previous articles:

Latest articles:


Popular related articles
Holy C++

Date: 23 Nov 2022

Author: Guest

In this article, I'll try to list all things that we can throw out of C++ without remorse. This won't cost us anything but will reduce the standard (and our headaches), take the burden off the compil…
Lifetime extension of temporary objects in C++: common recommendations and pitfalls

Date: 01 Nov 2022

Author: Guest

After reading this article, you will learn the following: ways to extend the lifetime of a temporary object in C++, various tips and tricks; pitfalls of the lifetime extension that a C++ programmer m…
How we were looking for a bug in PVS-Studio or 278 GB of log files

Date: 28 Oct 2022

Author: Grigory Semenchev, Sergey Larin, Phillip Khandeliants

Here is an interesting story of how our team were looking for a bug in the PVS-Studio analyzer. Well, we make mistakes too. However, we are ready to roll up our sleeves and dive deep into the rabbit …
Examples of errors that PVS-Studio found in LLVM 15.0

Date: 25 Oct 2022

Author: Andrey Karpov

Compilers are evolving: they issue more and more warnings. Do developers still need to use static code analyzers like PVS-Studio? Yes, because analyzers are evolving too. In this article you'll see h…
How PVS-Studio prevents rash code changes, example N6

Date: 20 Oct 2022

Author: Vladislav Stolyarov

Developers often make mistakes accidentally, or because they are in a hurry. Wondering how to find such mistakes quickly? Welcome to another article in the "How PVS-Studio prevents rash code changes"…

Comments (0)

Next comments
Unicorn with delicious cookie
Nous utilisons des cookies pour améliorer votre expérience de navigation. En savoir plus