通过减法签名无符号

Question

I've recently decided to make the leap and read through a bunch of computer science books to better equip myself for the future.

At the moment I'm reading through converting signed to unsigned decimals. I understand the majority if it (hopefully it becomes easier to eventually), but struggling with the following (in 32-bit):

-2147483647-1U < -2147483647

According the book, this evaluates to true. There's a bit about this that I'm still struggling with as I cant see why it evaluates to this.

With my understanding, I know that they are both converted to unsigned values in this calculation due to the first number being cast as unsigned. The first number is therefore -2147483648 after subtraction and then converted to unsigned, or does that unsigned conversion happen prior to the subtraction?

Sorry for the lengthy post, just trying to get my head around understanding this.

Thanks!

Answer 1

The first number is therefore -2147483648 after subtraction and then converted to unsigned, or does that unsigned conversion happen prior to the subtraction?

The latter is true. According to C11 Standard "6.3.1.8 Usual arithmetic conversions" :

...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.

So, all of the operands, both the ones for subtraction and for the comparison are converted to unsigned.

PS For completeness, the conversion procedure is described in "6.3.1.3 Signed and unsigned integers" :

... if the new type is unsigned, the value is converted by repeatedly adding or subtracting one more than the maximum value that can be represented in the new type until the value is in the range of the new type.

PPS The answer is assuming int being 32-bit long. If it is less than that, then the negative constant -2147483647 will have type long which is higher rank than unsigned int , which is 1U and then the above will not apply and no conversion will be performed (thanks @Olaf for pointing out).

Answer 2

The first number is therefore -2147483648 after subtraction

Not quite. The conversion to unsigned happens first. With mixed int/unsigned math, the int is converted to an unsigned .

Subtracting 2 unsigned results in an unsigned and an unsigned is never negative.

---

Assume 32-bit or wider unsigned/int

-2147483647-1U is a int minus an unsigned , so -2147483647 is converted to unsigned 2147483649 and the difference is unsigned 2147483648 . Now an unsigned is compare to an int , so the int is converted to unsigned 2147483649 . The left is less than the right, so the result is true.

---

[Edit]

Assume narrower than 32-bit unsigned/int , yet long uses the common 2's complement encoding. Often seen in embedded 8/16-bit processors in 2017.

-2147483647-1U is a long minus a narrower unsigned , so -2147483647 remains a long and 1U is converted to int 1 and the difference is long -2147483648 . Now an long is compare to an long . The left is less than the right, so the result is true.

Answer 3

Both are promoted to unsigned and -2147483647-1U == 0x8000000 , (unsigned)-2147483647 == 0x80000001 .

0x8000000 < 0x8000001 is true

same with signed only

-2147483647-1 == `-2147483648`
-2147483648 < -2147483647

Answer 4

It's really quite simple. According to 6.3.1.8 Usual arithmetic conversions if an int meets an unsigned int in an operation, the operands are both converted to unsigned int .

The conversion formalized as repeatedly adding or subtracting one more than maximum value that can be represented in the new type really describes how natural signed/unsigned reinterpretation works in two's complement arithmetic (the most common way, though not the only way, to represent signed integers in hardware).

Two's complement arithmetic on a 32 bit signed number works as follows:

• the most significant bit, if set, stands for -2^31
• the rest stand for themselves

-2147483647 is therefore 2^31+1 == 0b10000000000000000000000000000001 . Now since it comes into a subtraction operation with 1U ( 0b00000000000000000000000000000001 ), you should convert it to a uint32_t number by repeatedly adding or subtracting UINT32_MAX+1 == 2^32 , which after overflow will result in the same binary representation (the rules, I suppose, were made so that the bits could be straightforwardly reinterpreted on 2's complement (most common) platforms), and subtracting 1U from it will straightforwardly yield 0b10000000000000000000000000000000 == 2^31 , which is less than 2^31+1 .