Why is type conversion int32_t to uint32_t a Sign Change Integer Conversion Overflow Defect in Polyspace?

Code generated for a division operation with 'Floor' rounding and 'int32' output datatype is generating a Polyspace Defect: 'Sign Change Integer Conversion Overflow'. The supposed overflow occurs in the code where the absoute value of the numerator is calculated. When the numerator is negative, the value is cast as an uint32_T before calculating the two's complement to make it positive. I don't understand how this can overflow. Is this a bug with Polyspace?

Example:

int32_T div_s32_floor(int32_T numerator, etc ...)
{
uint32_T absNum;
...
absNum = (numerator < 0) ? ((~((uint32_T)numerator)) + 1U): ((uint32_T)numerator);
...
}
/* function call */
div_s32_floor(int32_t numerator, etc...);

Answer 1

[Andy Bartlett]

First, two suggestions

Here are two suggestions that can improve the efficiency of your generated code and may make the analysis concern go away.

1) Consider changing the rounding mode specified on the block creating the division from Floor to Simplest. The C99 specification requires signed integer division to round to zero. Round to floor is lean for other operations, but requires extra work for division. Simplest will automatically use Zero rounding for division and Floor for other operations to maximize efficiency.

2) If the target provides a long long type, consider allowing Embedded Coder to use it. It's a simple checkbox setting change that will avoid most use of 32 bit multiplication and division helper functions and give more efficient generated code.

Regarding the analysis

I assume Polyspace is flagging this C expression.

((uint32_T)numerator)

This can trigger a sign change overflow. Consider the case where numerator has value -1.

Let's simulate that behavior using fi objects.

numerator = fi(-1,1,32,0)
unsignedExpression = removefimath( fi(numerator,0,32,0,'OverflowAction','Wrap') )

which produces this output.

numerator = 
    -1
      numerictype(1,32,0)
unsignedExpression = 
                4294967295
      numerictype(0,32,0)

The change of the value from -1 to 4294967295 is an example of the sign change overflow that Polyspace is flagging.

Even though it is flagged, the behavior of the code is fully correct. The C standard requires that cast from signed 32 to unsigned 32 will wrap modulo 2^32, so this well defined behavior is intentionally and correctly used by the generated C code.

Overflow definition is "in the eye of the beholder"

Perhaps your question is related to the surprising complexities of the meaning of integer overflow. MathWorks tools classify changes of value in type conversions that are due to modulo 2^NBits wrapping as overflows. Let's call this the "common" meaning of overflow. However, the C specification declares that casts to unsigned types that change value due to modulo 2^NBits wrapping are just providing the defined behavior and are not overflows. So the C standard definition and the "common" meaning of overflow disagree for operations going to unsigned types. Polyspace is giving an alert based on the common meaning of overflow.

[Caleb Owen]

Thanks Andy! This answered my question. It appears that my confusion was related to Matlab's definition of overflow in this context.