Signed/unsigned mismatch when comparing two unsigned values using a conditional operator

Question

I have the following C code:

unsigned int a;
unsigned char b, c;
void test(void) {
    if (a < b)
        return;
    if (a < (b ? b : c))
        return;
}

When I compile it (with Microsoft cl, from MS SDK 7, -W3 warning level), the second comparison emits a warning: C4018, signed/unsigned mismatch. The first comparison emits no warning.

I've checked MS docs on the conditional operator and they says that if both operands are of same type, the result will be of the same type, so it should work as the first comparison. Am I missing something?

UPD: tested with gcc -Wall -Wextra -pedantic and got no warnings whatsoever.

Answer 1

This is probably due to the arithmetic conversion rules: First, any integer type of conversion rank less than int (eg unsigned char) will promote to int or unsigned int.

Whether the result will be int or unsigned int does not (directly) depend on the signedness of the original type, but its range: int is used even for unsigned types as long as all values can be represented, which is the case for unsigned char on mainstream architectures.

Second, as both operands end up with the same conversion rank, but one is unsigned, the other operand will be converted to an unsigned type as well.

Semantically, your expressions read

a < (unsigned int)(int)b

and

a < (unsigned int)(b ? (int)b : (int)c)

The compiler is apparently smart enough to notice that the first case cannot cause problems, but fails for the second one.

Steve Jessop's comment nicely explains how this could happen:

I would imagine that in the first case the compiler thinks, "I have a comparison operator whose operand types are unsigned int and unsigned char. No need for a warning, now let's apply promotion followed by usual conversion".

In the second case it thinks, "I have a comparison operator whose operand types are unsigned int and int (which I derived as the type of the conditional expression on the RHS). Best warn about that!".