C: uint16_t subtraction behavior in gcc

Question

I'm trying to subtract two unsigned ints and compare the result to a signed int (or a literal). When using unsigned int types the behavior is as expected. When using uint16_t (from stdint.h) types the behavior is not what I would expect. The comparison was done using gcc 4.5.
Given the following code:

unsigned int a;
unsigned int b;

a = 5;
b = 20;

printf("%u\n", (a-b) < 10);

The output is 0, which is what I expected. Both a and b are unsigned, and b is larger than a, so the result is a large unsigned number which is greater than 10. Now if I change a and b to type uint16_t:

uint16_t a;
uint16_t b;

a = 5;
b = 20;

printf("%u\n", (a-b) < 10);

The output is 1. Why is this? Is the result of subtraction between two uint16_t types stored in an int in gcc? If I change the 10 to 10U the output is again 0, which seems to support this (if the subtraction result is stored as an int and the comparison is made against an unsigned int than the subtraction results will be converted to an unsigned int).

Aubreir

The result is not just "stored in an int'. The entire subtraction is performed as int subtraction, i.e. both uint16_t operands are converted to int before the subtraction even has a chance to begin. Read about integral promotions. – Stibine

Answer 1

Because calculations are not done with types below int / unsigned int (char, short, unsigned short etc; but not long, unsigned long etc), but they are first promoted to one of int or unsigned int. "uint16_t" is possibly "unsigned short" on your implementation, which is promoted to "int" on your implementation. So the result of that calculation then is "-15", which is smaller than 10.

On older implementations that calculate with 16bit, "int" may not be able to represent all values of "unsigned short" because both have the same bitwidth. Such implementations must promote "unsigned short" to "unsigned int". On such implementations, your comparison results in "0".

Context

Answer 2

Before both the - and < operations are performed, a set of conversions called the usual arithmetic conversions are applied to convert the operands to a common type. As part of this process, the integer promotions are applied, which promote types narrower than int or unsigned int to one of those two types.

In the first case, the types of a and b are unsigned int, so no change of types occurs due to the - operator - the result is an unsigned int with the large positive value UINT_MAX - 14. Then, because int and unsigned int have the same rank, the value 10 with type int is converted to unsigned int, and the comparison is then performed resulting in the value 0.

In the second case, it is apparent that on your implementation the type int can hold all the values of the type uint16_t. This means that when the integer promotions are applied, the values of a and b are promoted to type int. The subtraction is performed, resulting in the value -15 with type int. Both operands to the < are already int, so no conversions are performed; the result of the < is 1.

When you use a 10U in the latter case, the result of a - b is still -15 with type int. Now, however, the usual arithmetic conversions cause this value to be converted to unsigned int (just as the 10 was in the first example), which results in the value UINT_MAX - 14; the result of the < is 0.

Elastomer

"it is apparent that on your implementation the type int can hold all the values of the type uint16_t" that's the key, nevertheless I'm surprised that gcc (Linux) does that unsigned short to int promotion (and not to unsigned) before performing the comparison (which in my case was not the expected result)... The GNU folks have surely a good reason for this choice, but I think that can be misleading to have all values unsigned and then do the comparison with a negative operand... Maybe the promotion should only be done up to the largest type (16 bits here). – Planar

@e2-e4: These promotion rules are part of the C standard, not something the compiler authors decided on. The rule of thumb to remember is that arithmetic is never done in types narrower than int / unsigned int, so if you are dealing with narrower unsigned types and want to control the type in which the arithmetic is done, convert an operand to unsigned int explicitly. – Elastomer

Answer 3

[...] Otherwise, the integer promotions are performed on both operands. (6.3.1.8)

Lexington

Answer 4

When uin16_t is a sub-range of int, (a-b) < 10 is performed using int math.

Use an unsigned constant to gently nudge the left side to unsigned math.

// printf("%u\n", (a-b) < 10);
printf("%d\n", (0u + a - b) < 10);  // Using %d as the result of a compare is int.
// or to quiet some picky warnings
printf("%d\n", (0u + a - b) < 10u);

(a - b) < 10u also works with this simple code, yet the idea I am suggesting to to perform both sides as unsigned math as that may be needed with more complex code.

Pani