# How PVS\-Studio prevents rash code changes, example N5

The PVS\-Studio static analyzer encompasses the symbolic execution mechanism\. And today we have a great opportunity to demonstrate how this feature helps find errors\.

![0936_Blender_prevents_rash_code_changes_N5/image1.png](https://import.viva64.com/docx/blog/0936_Blender_prevents_rash_code_changes_N5/image1.png)

Our [system](https://pvs-studio.com/en/blog/posts/cpp/0799/) regularly monitors the Blender project and emails me a daily report about potential errors in new or changed code\. I don't write a note for each error the system detects\. This many notes would probably spam our blog\. Today's case, however, is different\.

The PVS\-Studio static analyzer [uses many technologies](https://pvs-studio.com/en/blog/posts/0908/) to find bugs and potential vulnerabilities\. 

Symbolic execution enables the analyzer to evaluate expressions when values for variables are unavailable\. Sounds mysterious, doesn't it? Don't fret, below we'll examine a practical example, and everything will become clear\. Let's take a look at [this commit](https://github.com/blender/blender/commit/48014fbf1432de2ad74ef76280673062d9870af7) in the Blender project\.

The analyzer reports a problem in the 868th code line:

```cpp
memset(&path->ptr[i], 0, sizeof(path->ptr[i]) * (path->len - i));
```

The analyzer finds it suspicious that the _memset_ function does not fill the memory:

\[CWE\-628\] [V575](https://pvs-studio.com/en/docs/warnings/v575/): The 'memset' function processes '0' elements\. Inspect the third argument\.

Let's figure out how the analyzer came to this conclusion\.

The analyzer does not know which numeric values can be stored in the _path\-\>len_ variable\. However, the analyzer can work with this variable in another way \- I'll elaborate later on as to how\.

There's a bit more information about the _i_ variable\.

```cpp
for (int i = 0; i < path->len; i++) {
  ....
  if (i != 0) {
    ....
    memset(&path->ptr[i], 0, sizeof(path->ptr[i]) * (path->len - i));
```

From the code above, the analyzer can get the following information:

1. The _i_ variable is less than _path\-\>len_\. This data comes from loop analysis\.
1. The _i_ variable is greater than 0\. The analyzer makes this conclusion from how this variable is first initialized inside the loop and then checked against zero\.

Consequently, the possible values of the _i_ variable lie within the range from 1 to _path\-\>len_\.

However, this information is still insufficient to make any conclusions\. That's when the symbolic execution mechanism comes to the rescue\.

The analyzer sees that, before the _memset_ function call, the _path\-\>len_ variable value changes in the following way:

```cpp
path->len = i;
if (i != 0) {
  memset(&path->ptr[i], 0, sizeof(path->ptr[i]) * (path->len - i));
```

The _path\-\>len_ variable value equals _i_\. This mechanism makes it possible for the analyzer to evaluate expressions without knowing the ranges of possible variable values\. When working with such expressions, the analyzer makes a substitution:

```cpp
sizeof(path->ptr[i]) * (i - i)
```

And gets zero as the function's third argument:

```cpp
sizeof(path->ptr[i]) * 0
```

This is obviously an anomaly, and PVS\-Studio reports this problem to the developers\. What we see here is some kind of an error someone made when editing code\. It's pretty cool that developers — if they are using a static analysis tool — can notice such issues quickly and fix them right then and there\.

**Note\.** Since this article lists only a small code fragment, the _path\-\>len \= i_ assignment can seem very strange\. This would mean that the loop always ends after the first iteration\. However, in the project, the code fragment we're discussing in this article is placed under conditions and such code makes sense\. [Here](https://github.com/blender/blender/commit/48014fbf1432de2ad74ef76280673062d9870af7) you can examine the loop's entire code\.

**Previous posts:**

1. [How PVS\-Studio prevents rash code changes, example N4](https://pvs-studio.com/en/blog/posts/cpp/0924/)
1. [How PVS\-Studio prevents rash code changes, example N3](https://pvs-studio.com/en/blog/posts/cpp/0922/)
1. [How PVS\-Studio prevents rash code changes, example N2](https://pvs-studio.com/en/blog/posts/cpp/0910/)
1. [How PVS\-Studio prevents rash code changes](https://pvs-studio.com/en/blog/posts/cpp/0817/)
1. [PVS\-Studio, Blender: series of notes on advantages of regular static analysis of code](https://pvs-studio.com/en/blog/posts/cpp/0807/)