Static analysis protects your code from time bombs

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.

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.