if-statement with two checks with different data types

[MaWu]

Hi everyone!

I have a question about rule 10.1 and 10.2
Whenever I try to work with an if or while and use two comparions which are logically connected I get an MISRA issue when the two comparisons have different data types.
e.g. int16 and int32
Because the results of the two comparions is somehow boolean I would not expected to get:
The value of an expression implicitly converted to a different type.

Is it really an issue? I know I can cast both to the same data type but it looks strange.

Example:

Code:

t_int8 a = 3;
t_uint16 b = 7;
  
if ((a > 3) && (b > 5u))
{
   a++;  
}

[misra-c]

Both of (a > 3) and (b > 5u) have int type according to the C standard and an effectively Boolean type for purposes of MISRA C as described in the Glossary.

There is no arithmetic type conversion taking place on the operands of the && operator. Depending on the definition of the types t_int8 and t_uint16, there may be promotion and/or balancing conversions taking place on the operands of the > operators but these have no effect on the type of their results.

It seems that the MISRA checker that you are using is not configured properly or is not performing the check correctly.

[Lundin]

Is that really correct? If "int" on the particular system is 16 bits, then

a will be integer promoted to type int.
3 is of type int.
(a > 3) will be of type int.

b will remain unsigned int
5u will remain unsigned int
(b > 5u) will be of type unsigned int

(a > 3) && (b > 5u), the usual arithmetic conversions take place, converting the left-side expression to unsigned int.

[mishak]

Yes, it is correct. The standard states that the relational operators yield a result of type int.

[Lundin]

ISO 9899:1999 6.5.8 Relational operators
"3 If both of the operands have arithmetic type, the usual arithmetic conversions are
performed."

ISO 9899:1999 6.3.1.8 Usual arithmetic conversions
... (rules for floats)

"Otherwise, the integer promotions are performed on both operands. Then the following rules are applied to the promoted operands:

If both operands have the same type, then no further conversion is needed.

Otherwise, if both operands have signed integer types or both have unsigned
integer types, the operand with the type of lesser integer conversion rank is
converted to the type of the operand with greater rank.

Otherwise, if the operand that has unsigned integer type has rank greater or
equal to the rank of the type of the other operand, then the operand with
signed integer type is converted to the type of the operand with unsigned
integer type.

Otherwise, if the type of the operand with signed integer type can represent
all of the values of the type of the operand with unsigned integer type, then
the operand with unsigned integer type is converted to the type of the
operand with signed integer type.

Otherwise, both operands are converted to the unsigned integer type
corresponding to the type of the operand with signed integer type."


If the above is different in C90, then please ignore my post. I suspect it is worded exactly the same, however.

[mishak]

The relevant section in C99 is 6.5.8(6):

Each of the operators(greater than), = (greater than or equal to) shall yield 1 if the specified relation is true and 0 if it is false. The result has type int.

The usual arithmetic conversions take place on the operands before the the comparison takes place.

[Lundin]

I just found that rule too. So either operand is guaranteed to be int, by this special rule for the relational operators. However, the operands are still subject to the usual arithmetic conversions for the sake of evaluating the operands, so there could be implicit conversions still, just not in this particular example.

[misra-c]

Yes, but see also C99 Section 6.3.8 paragraph 6 and Section 6.3.9 paragraph 3. These state that the results of relational and equality operators respectively have type int.

The type of the result is independent of the promotions and usual arithmetic conversions that may be performed on the operands of relational and equality operators.