Pour obtenir une clé
d'essai remplissez le formulaire ci-dessous
Demandez des tariffs
Nouvelle licence
Renouvellement de licence
--Sélectionnez la devise--
USD
EUR
RUB
* 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.

>
>
>
How PVS-Studio prevents rash code chang…

How PVS-Studio prevents rash code changes, example N2

18 Jan 2022
Author:

When developers do make mistakes, it's often accidental or because the developers are in a hurry. These errors often make their way into small edits to the code. Let's review one of these cases: a developer fixes an error and introduces a new one simultaneously.

0910_Blender_V595/image1.png

Actually, the image above already demonstrates everything. You do not even need to read any further :). However, I would still like to talk about what we see here, so that's what I'm going to do.

Back in 2021, I started monitoring Blender - an open-source project - for errors. I employed the PVS-Studio analyzer to scan it and find errors. Since Blender is developing at a quick pace, I was getting PVS-Studio's warnings to new code quite frequently. Unfortunately, I could not react to them in a timely manner, because I was busy with everything else. Lots of meetings, one article after the other - and some else in between. So I basically missed most of these warnings :( . As a result, during that year, I only posted a couple of notes about fresh errors - though I could have written more.

Yesterday I noticed a new message with two warnings. So, I thought, why not take a look? Especially since I had a couple of minutes. One warning was not all that interesting, while the second one was quite a find. It was definitely a sign for me to focus and write how PVS-Studio can detect errors if used regularly :).

So, @Antonioya committed two new lines that were intended to fix the following bug: Fix T94903: GPencil: Copying keys doesn't preserve Keyframe Type.

The developer was in a hurry and never noticed that the pointer he worked with could be null. The project's code contains a nullptr check that proves it:

gpf->key_type = gpfs->key_type;
if (gpf) {

In its turn, the PVS-Studio analyzer detected an anomaly and issued a warning: V595 [CWE-476]: The 'gpf' pointer was utilized before it was verified against nullptr. Check lines: 458, 459. editaction_gpencil.c

And that's a sure way to notice many mistakes and save time one'd spend fixing them. It's way easier for that same developer to come back to the code they wrote and fix it than for the company for fix this bug when it gets to QA or users.

P.S. First I wanted to simply name the article "How PVS-Studio prevents rash code changes", but then I discovered we already have an article with this name. So I added "example N2". I hope that with time we will write more and more of such articles. Thank you for your time - and have a shot at incorporating PVS-Studio into your development process!

Comments (0)

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