Polyspace Bug Finder detects SEI CERT C ARR30-C and MEM35-C violation in the same line but doesn't provide details in Polyspace Access

Greetings,

Polyspace Bug Finder (2022b) detects the violations SEI CERT C ARR30-C and MEM35-C in the same line but when checking the results inside the Polyspace Access application there are not much details on when the actuall problem occurs (see the picture below which is from the Polyspace Access, please note that the function name and file name is blured).

Since the function is called in multiple places it is unclear which instance is causing the violations, by manual inspection of the functions and arguments, together with the tests no problems were observed.

The dummy code example is below that represents usage and the violation of the function:

typedef struct s_test_struc
{
    uint8 test_var1[15];
    uint8 test_var2[1];
    uint8 test_var3[]; // flexible array (size of array is 1)
} test_struc;

test_struc test_struc_var;

#define test_struc_var_m (&test_struc_var)

uint8 function_where_the_violation_is_detected (const uint8 *var1, uint8 *var2, uint8 *var3)
{
    uint8 local_var = *var1 - *var2;
    uint8 ret_val = 0;
    if(loacl_var > 0)
    {
        ret_val = (*var3) + (uint8)1; // ARR30-C/MEM35-C violation detected on the (*var3)
	}
    return ret_val;
}

uint8 caller_function (void)
{
    uint8 ret_val = 0;
    // test_struc_var is initialized with 0 using memset in some other function
    function_where_the_violation_is_detected(&(test_struc_var_m->test_var1[2])
                                             ,&(test_struc_var_m->test_var2[0])
                                             ,&(test_struc_var_m->test_var3[0]))
}

Is there a possible way that Polyspace Bug Finder provides more details regarding the violation?

Is it possible that the violation is detected due to flexible array usage or similar corner case?

Best Regards,

Nebojsa

Answer 1

[Anirban]

I tried running Polyspace Bug Finder R2022b on your example and I see some more details associated with the result (I am showing the results as seen in the desktop product, but it should be the same on Polyspace Access). See here:

It seems that the size of the flexible array member cannot be determined from the code you have, so Polyspace is assuming zero size (which is the case by default). I modified the example to actually allocate memory for the structure with the flexible array member (such that the array member has size 1) and the violation no longer occurs.

Original code

typedef unsigned char uint8;

typedef struct s_test_struc
{
    uint8 test_var1[15];
    uint8 test_var2[1];
    uint8 test_var3[]; // flexible array (size of array is 1)
} test_struc;

test_struc test_struc_var;

#define test_struc_var_m (&test_struc_var)

uint8 function_where_the_violation_is_detected (const uint8 *var1, uint8 *var2, uint8 *var3)
{
    uint8 local_var = *var1 - *var2;
    uint8 ret_val = 0;
    if(local_var > 0)
    {
        ret_val = (*var3) + (uint8)1; // ARR30-C/MEM35-C violation detected on the (*var3)
	}
    return ret_val;
}

uint8 caller_function (void)
{
    uint8 ret_val = 0;
    // test_struc_var is initialized with 0 using memset in some other function
    function_where_the_violation_is_detected(&(test_struc_var_m->test_var1[2])
                                             ,&(test_struc_var_m->test_var2[0])
                                             ,&(test_struc_var_m->test_var3[0]));
}

To fix the issue, instead of:

#define test_struc_var_m (&test_struc_var)

Allocate memory to test_struc_var_m using an allocation statement like the following (and ofcourse, deallocate later):

test_struc* test_struc_var_m = malloc(sizeof(test_struc) + sizeof(char));

Now, the sizeof(char) in the allocation makes sure that the flexible array member has size 1.

Answer 2

[Nebojsa]

Hello Anriban,

Thank you for the answer and your support.

I completely agree with your comment regarding the memory allocation.

One strange thing is that when running the same Polyspace BugFinder in the same environment, but in a different project that has this same piece of code, this violation is not detected at all.

Is there any other way that we get more information and detail about this particular violation when running it in the Polyspace Access web app (like on the picture you attached, that it says what exactly is out of range), so based on those details we can figure out why in other cases this violation did not occur? Or do you know if something can cause this lack of information, that the tool does not give us these "Expected" and "Actual" values (maybe some configuration option is missing or similar)?

Thanks in advance,

Nebojsa

[Anirban]

There is no configuration option to turn on the Expected and Actual values, as far as I am aware of.

I have to make certain guesses about what is going on here:

1. You might be using a different version of R2022b (I used the latest update) and the additional information was added in an update. It is unlikely but might happen. Nevertheless, it might be worth upgrading to a more recent release (R2023a or R2023b).
2. Your actual code might be substantially different from the code snippet you provided (in a way that Bug Finder detects the defect but is unable to provide the actual values). Can you check with the exact code snippet in my previous answer and see if the Expected and Actual values don't show up? If it still doesn't show up, it might be a version mismatch or something else that you have to contact MathWorks Technical Support to investigate further.