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.

>
>
>
Static analysis protects your code from…

Static analysis protects your code from time bombs

04 Aoû 2021
Author:

Static code analysis allows you to identify and eliminate many defects at an early stage. Moreover, it's possible to detect dormant errors that don't show themselves when they appear. They can cause many problems in the future and it requires many hours of debugging to detect them. Let's look at an example of such a dormant error.

0848_Timebomb/image1.png

To show the advantage of regular use of the PVS-Studio static analyzer, we regularly check the Blender project. My colleague wrote more about this idea here.

Sometimes I keep an eye on the warnings generated for new or modified Blender code. New bugs appear regularly, but most of them are boring or minor. With patience of a fisherman I'm sitting here waiting for something interesting that is worth writing about. And today's article is a case in point.

void UI_but_drag_set_asset(uiBut *but,
                           const AssetHandle *asset,
                           const char *path,
                           int import_type,
                           int icon,
                           struct ImBuf *imb,
                           float scale)
{
  ....
  asset_drag->asset_handle = MEM_mallocN(sizeof(asset_drag->asset_handle),
                                         "wmDragAsset asset handle");
  *asset_drag->asset_handle = *asset;
  ....
}

The code must allocate a buffer in memory sufficient to store a structure of the AssetHandle type. It is a programmer's intent. But it allocates a buffer equal not to the size of the structure, but to the size of the pointer.

Here is the error:

sizeof(asset_drag->asset_handle)

The correct version:

sizeof(*asset_drag->asset_handle)

The analyzer detected this error and issued a warning: V568: It's odd that ' sizeof()' operator evaluates the size of a pointer to a class, but not the size of the 'asset_drag->asset_handle' class object. interface.c 6192

It's simple. It's a classic error pattern that we encounter in various projects. Something else is worth noting! This code works correctly now! The author who made it is lucky. Let's look at what the AssetHandle structure is:

typedef struct AssetHandle {
  const struct FileDirEntry *file_data;
} AssetHandle;

The structure now has exactly one pointer. It turns out that the size of the structure is the same as the size of the pointer!

Look at a pretty time bomb right in front of us. This code will work safely and steadily for years. It will function fully until someone wants to add a new field to the structure.

At this point, the app crashes. And it's not clear what and where exactly it crashed. Less memory allocates for the structure than is required. That's great if a programmer is lucky enough to get an Access Violation after violating the buffer boundary. But, more likely, some memory will simply get corrupted. As a result, a developer may be doomed to torturously debug code for hours.

Use static code analyzer to significantly improve the quality and reliability of code. It's useful both in the short and long term.

Static analysis can't detect all errors. However, the benefits of its regular use are greater than the cost of reviewing a daily report with new warnings. Recently, in the article, a user of our analyzer concluded: you'd better run the analyzer than debug for three days.

Comments (0)

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