INPUTS AND STUBBING: INIT GLOBAL VARIABLES THROUGH CONSTRAIN_SETUP

Hi @Anirban,

How to init global variables with specific size by Input + Stubbing?

I have tried to do it through constrain setup, but i seems not work. The orange warning still happend after i init for ponter input.

here is my config, please help me if you can.

Sincerely,

Answer 1

[Anirban]

You initialized argument 1 of function Bcd_copysignal with the following constraints:

• The pointer is not NULL.
• The pointer is actually an array with multiple elements.
• The array has max elements.

Assuming ult_ArDstSignalData is that argument 1, your expectation is that the array ult_ArDstSignalData should be accessible at any index. This expectation seems to be correct. Can you show the message that you see for the Illegally dereferenced pointer warning that occurs on line 994?

Also, do you have any warnings in the analysis log that contains the text data-range-specifications?

[Tran Thang]

This is message in line 994.

This is ID8805 has same problem with DRS: Do you have any idea?

[Anirban]

I can see how the DRS does not apply here, but to provide you a better solution would require some access to the codebase being analyzed.

When specifying a DRS on argument 1 of function Bcd_copysignal with:

• Init Mode set to INIT
• # Allocated Objects set to max

What you are essentially saying is this - At the start of function Bcd_copysignal, consider that the argument 1 of the function is a pointer that points to an array with max objects (max being a very large number). However, this is true only at the start of the function because you set the Init Mode set to INIT. The moment the pointer is assigned to a buffer, the constraint stops applying. Now, the code has taken over and any constraint on the pointer comes from the code. Your orange Illegally dereferenced pointer check might be happening after the external constraint has stopped applying (I cannot tell what is happening from just the screenshots).

You have a few options here:

• Since you are constraining the # Allocated Objects to max and expecting to get rid of the Illegally dereferenced pointer check, you are essentially saying that you have reviewed the check and think that the pointer dereference is ok (by putting max, you are making the pointer point to a very large array, so any access within the array will not be out of bounds). If you have indeed determined that the dereference is ok, you can add a justification to the result or code. See Address Polyspace Results Through Bug Fixes or Justifications. Instead of having a process where you want all checks to be green, the correct approach is to have a process where all checks must be green or justified orange. Orange checks are basically situations where the product could not definitely prove the presence or absence of a run-time error. These require some manual review to determine if the orange check represents a real error or a false positive from some approximation/assumption. After a manual review, if you think that the error cannot happen, you can add a justification (for instance, set the Status to No Action Planned). At the end, all checks must be either green or justified orange. The Software Quality Objectives help with this approach.
• In this case, just from the screenshots provided, I am not sure the pointer dereference is ok. I have these questions:

1. How is the pointer in the message on result with ID 267 pointing to several local variables? Is it a global pointer? Or, is the pointer being passed down a function call hierarchy?
2. Why is the message on result with ID 8805 suggesting to put DRS on several functions?

Especially in the second screenshot, what seems to be the case is -

The pointer points to two buffers in the course of its lifetime - one with size 52 bytes and another with 2^27-2 bytes. On the line with the Illegally dereferenced pointer check, it might be pointing to the second buffer, in which case, the dereference is ok. But if it is pointing to the first buffer, the dereference is not ok. If I had access to the code, I would right-click the pointer, search for all references and determine which of the two is the case.

This is a situation where MathWorks Technical Support can help you with a more thorough investigation.

[Tran Thang]

Hi Anirban,

Thanks for your great support. I'd like to answer you that:

1. After analizing data, the pointer is passed by some calls hierachy and some constrains inside these functions.
2. I don't know how CP suggest put DRS to these ID such as 267 and 8805. So, is DRS really work in the end?

Best regard,

[Anirban]

I cannot give a definitive answer without looking at the function call hierarchy. You can track the error call graph that leads to a given check. See Result Details.

Let us say that one of the paths that leads to the check contains the calls main -> func1 -> func2. Now, you can check whether the pointer is written explictly in the code in any of these functions (and the write operation occurs on an execution path before the check). These explicit writes will override external constraints. If the check occurs after that point, then the DRS no longer applies and will not work.

But this investigation will take some work, and I cannot give a more precise answer based on the screenshot.