Question

Possible Duplicate:
How do promotion rules work when the signedness on either side of a binary operator differ?

I’m trying to wrap my head around integer promotion and overflow in C++. I’m a bit confused with several points:

a) If I have the following code segment:

int i = -15; 
unsigned j = 10; 
std::cout << i + j;

I get out -5 % UINT_MAX. Is this because the expression i + j is automatically promoted to an unsigned? I was trying to read the standard (4.13):

— The rank of any unsigned integer type shall equal the rank of the corresponding signed integer type.

I’m not sure if I’m reading this incorrectly, but if that is true, why is i + j ending up as unsigned?

b) Adding onto the previous segment, I now have:

int k = j + i;

That is getting evaluated to -5. Shouldn’t the expression j + i be evaluated first, giving 4294967291 on my system, and setting that equal to j? That should be out of bounds, so is this behavior undefined? I’m not sure why I get -5.

c) If I change the segment from a) slightly using short, I have:

short i = -15;
unsigned short j = 10;
std::cout << i + j;

I figured when I did this, I would get the same result as a), just with -5 % USHRT_MAX. However, when I execute this, I get -5. Why does using short give a different value than int?

d) I have always learned that the overflow behavior of a signed integral is undefined. For example: int r = ++INT_MAX would be undefined.

However, if there was an unsigned overflow, the quantity would be defined. For example: unsigned a = ++UINT_MAX, then a would be 0. Is that correct?

However, the standard didn’t seem to say anything about it. Is that true? If so, why is that?

Answer 1

a) From §5/9:

Many binary operators that expect operands of arithmetic or enumeration type cause conversions and yield result types in a similar way. The purpose is to yield a common type, which is also the type of the result. This pattern is called the usual arithmetic conversions, which are defined as follows:

• If either operand is of type long double, the other shall be
  converted to long double.
• Otherwise, if either operand is double, the other shall be converted to double.
• Otherwise, if either operand is float, the other shall be converted to float.
• Otherwise, the integral promotions (4.5) shall be performed on both operands.
• Then, if either operand is unsigned long the other shall be converted to unsigned long.
• Otherwise, if one operand is a long int and the other unsigned int, then if a long int can represent all the values of an unsigned int, the unsigned int shall be converted to a long int; otherwise both operands shall be converted to unsigned long int.
• Otherwise, if either operand is long, the other shall be converted to long.
• Otherwise, if either operand is unsigned, the other shall be converted to unsigned.

[Note: otherwise, the only remaining case is that both operands are int]

Therefore, since j is unsigned, i is promoted to unsigned and the addition is performed using unsigned int arithmetic.

b) This is UB. The result of the addition is unsigned int (as per (a)), and thus you overflow the int in the assignment.

c) From §4.5/1:

An rvalue of type char, signed char, unsigned char, short int, or unsigned short int can be converted to an rvalue of type int if int can represent all the values of the source type; otherwise, the source rvalue can be converted to an rvalue of type unsigned int.

Therefore, since a 4-byte int can represent any value in a 2-byte short or unsigned short, both are promoted to int (per §5.9’s integral promotions rule), and then added as ints.

d) From §3.9.1/4:

Unsigned integers, declared unsigned, shall obey the laws of arithmetic modulo 2ⁿ where n is the number of bits in the value representation of that particular size of integer.

Therefore, UINT_MAX+1 is legal (not UB) and equal to 0.