Our website uses cookies to enhance your browsing experience.
Accept
to the top
close form

Fill out the form in 2 simple steps below:

Your contact information:

Step 1
Congratulations! This is your promo code!

Desired license type:

Step 2
Team license
Enterprise license
** By clicking this button you agree to our Privacy Policy statement
close form
Request our prices
New License
License Renewal
--Select currency--
USD
EUR
* By clicking this button you agree to our Privacy Policy statement

close form
Free PVS‑Studio license for Microsoft MVP specialists
* By clicking this button you agree to our Privacy Policy statement

close form
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

close form
I am interested to try it on the platforms:
* By clicking this button you agree to our Privacy Policy statement

close form
check circle
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.

>
>
>
Static analysis protects your code from…

Static analysis protects your code from time bombs

Aug 04 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.

Popular related articles


Comments (0)

Next comments next comments
close comment form