Why is 0 < -0x80000000?

在Leetcode的Pow(x, n)中，有一组特殊的测试数据，即1.0 -2147483648 （求1.0^-2147483648）。同时我也发现Stack Overflow上一个与之类似的问题和答案。提问和回复都很精彩，就着手翻译一下（其实是为了加深记忆）。

问题地址：Why is 0 < -0x80000000?

问：

#include <stdio.h>#define INT32_MIN        (-0x80000000)int main(void) {    long long bal = 0;    if(bal < INT32_MIN )    {        printf("Failed!!!");    }    else    {        printf("Success!!!");    }    return 0;}

条件if(bal < INT32_MIN) 总是真，与我的预期不符。
当我进行了修改#define INT32_MIN (-2147483648L) 后，程序正常工作。

答：
这很难察觉。
每一个整数字面值在你的程序中都有一个类型。这些类型有如下标准，如表6.4.4.1:

Suffix      Decimal Constant    Octal or Hexadecimal Constantnone        int                 int            long int            unsigned int            long long int       long int                                unsigned long int                                long long int                                unsigned long long int

如果一个数的字面值不能存放在默认的int 类型中，它将试图采用下一个类型（如表6.4.4.1)所示。所以对于十进制整数字面值，将进行如下过程：

• 尝试int
• 如果不能存放，尝试long
• 如果还不能存放，尝试long long

而十六进制的字面值的行为与上述过程大不相同。如果字面值不能存放在一个有符号类型如int 中，在它提升类型前会首先将尝试存放在unsigned int 。我们可以从表6.4.4.1中看出其中的差异。

所以在一个32位操作系统中，你的字面值是 0x80000000 是一个 unsigned int 类型。
这意味着你对它使用一元操作符- 将不能达到相应的效果（ 一元负运算符应用于无符号类型，结果仍为无符号类型）。另一种情况是它会造成一个有符号整数的溢出。相反的，你将得到值0x80000000 ，一个正值。

bal < INT32_MIN 将执行常见的算数类型转换，表达式中的0x80000000 将从unsigned int 转换为long long 类型存放，0小于0x80000000 ,因此产生了如此结果。

当你使用十进制形式将字面值替换为2147483648L 后，编译器将不再选择unsigned int ， 而是尝试将它存放在一个long 类型中。还有后缀L 意味着如果可能的话，你想用一个long 类型来进行存放。后缀L 通常遵守相同的规则（如表6.4.4.1）：如果这个数不能存放在它所请求的long 类型中，编译器将会给你一个long long 类型，直到它可以完成正确的存放。