MISRA C:2012 Rule 10.4

Both operands of an operator in which the usual arithmetic conversions are performed shall have the same essential type category

Description

Rule Definition

Both operands of an operator in which the usual arithmetic conversions are performed shall have the same essential type category¹ .

Rationale

The use of implicit conversions between types can lead to unintended results, including possible loss of value, sign, or precision.

For more information on essential types, see Essential Types in MISRA C Rules 10.x.

Polyspace Implementation

The checker raises a violation of this rule if the two operands of an operation have different essential types. The checker message states the types detected on the two sides of the operation.

The checker does not raise a violation of this rule if one of the operands is the constant zero.

If an operation has an unsigned integer operand and a signed integer constant operand, Polyspace^® does not report a violation if the signed constant has the same binary representation as its unsigned equivalent. For example, in this code, Polyspace assumes that the type of the expression (var + 1) is essentially unsigned integer because 1 and 1U has same binary representation::

unsigned int var;
int signed_var = (int) (var + 1);

This assumption makes the preceding code compliant with the rule.

Troubleshooting

If you expect a rule violation but do not see it, refer to Diagnose Why Coding Standard Violations Do Not Appear as Expected.

Examples

Operands with Different Essential Types

#define S64_MAX (9223372036854775807LL)
#define S64_MIN (-9223372036854775808LL)
long long input_s64_a, input_s64_b, result_s64;

void my_func(void){
   if (input_s64_a < S64_MIN + input_s64_b) { //Noncompliant: 2 violations
      result_s64 = S64_MIN;
   }
}

In this example, the type of S64_MIN is essentially unsigned. The value 9223372036854775808LL is one more than the largest value that can be represented by a 64-bit variable. Therefore, the value overflows and the result wraps around to a negative value, so -9223372036854775808LL is essentially unsigned.

The operation input_s64_a < S64_MIN + input_s64_b violates the rule twice.

• The + operation violates the rule. The left operand is essentially unsigned and the right operand is signed.

• The < operation also violates the rule. As a result of type promotion, the result of the + operation is essentially unsigned. Now, the left operand of the < operation is essentially signed but the right operand is essentially unsigned.

Check Information

Group: The Essential Type Model

Category: Required

AGC Category: Advisory

Version History

R2025a: true and false macros having value 1 and 0 considered essentially Boolean

Polyspace now considers the macros true and false from stdbool.h as essentially Boolean. If you specify the option -boolean-types, then the macros true/ TRUE/True and false/ FALSE/False are also considered essentially Boolean if they have values 1 and 0 respectively.

R2024a: Complex essential types now supported

To support MISRA C:2012 Amendment 3, this rule now takes essentially complex floating types into account. Binary operations where one of the operands is an essentially complex type are reported as violations of this rule if the other operand is an integral type, or an enumerator type. Binary operations involving essentially complex floating type and essentially real floating type is not a violation of this rule.