（-2147483648>0）在C中返回true？

Question

-2147483648是32位整数类型的最小整数，但它似乎会在if（…）中溢出 句子：

if (-2147483648 > 0)
    std::cout << "true";
else
    std::cout << "false";

这将在我的测试中打印true。但是，如果我们将-2147483648转换为整数，结果将不同：

if (int(-2147483648) > 0)
    std::cout << "true";
else
    std::cout << "false";

这将打印false。

我很困惑。有人能解释一下吗？

更新日期：2012年5月2日：

感谢您的评论，在我的编译器中，int的大小是4字节。我使用VC进行一些简单的测试。我改变了问题中的描述。

在这篇文章中，有很多非常好的回复，AndreyT对编译器在这样的输入上的行为以及这个最小整数是如何实现的给出了非常详细的解释。qPCR4vir另一方面给出了一些相关的“好奇心”以及整数是如何表示的。太令人印象深刻了！




Answer 1

简而言之，2147483648溢出到-2147483648，和（-2147483648）

这就是2147483648在二进制中的样子。

此外，在有符号二进制计算的情况下，最高有效位（“MSB”）是符号位。这个问题可能有助于解释原因。

Answer 2

编译器（VC2012）提升到可以保存值的“最小”整数。在第一种情况下，有符号的int（和long int）不能（在应用符号之前），但是无符号的int可以：2147483648有无符号的int？？？类型。在第二种情况下，您强制int从无符号。

const bool i= (-2147483648 > 0) ;  //   --> true

警告C4146:一元减号运算符应用于无符号类型，结果仍然无符号

以下是相关的“好奇”：

const bool b= (-2147483647      > 0) ; //  false
const bool i= (-2147483648      > 0) ; //  true : result still unsigned
const bool c= ( INT_MIN-1       > 0) ; //  true :'-' int constant overflow
const bool f= ( 2147483647      > 0) ; //  true
const bool g= ( 2147483648      > 0) ; //  true
const bool d= ( INT_MAX+1       > 0) ; //  false:'+' int constant overflow
const bool j= ( int(-2147483648)> 0) ; //  false : 
const bool h= ( int(2147483648) > 0) ; //  false
const bool m= (-2147483648L     > 0) ; //  true 
const bool o= (-2147483648LL    > 0) ; //  false

C 11标准：

2.14.2个整数文本[lex.icon]

…

整数文字是一个没有句点或指数部分的数字序列。整型文字可能有一个指定其基的前缀和一个指定其类型的后缀。

…

整型文字的类型是可以表示其值的对应列表的第一个。

如果整数文本不能由其列表中的任何类型表示，并且扩展整数类型（3.9.1）可以表示其值，则它可能具有该扩展整数类型。如果文本列表中的所有类型都是有符号的，则扩展整数类型应该是有符号的。如果文本列表中的所有类型都是无符号的，则扩展整数类型应为无符号的。如果列表同时包含有符号和无符号类型，则扩展整数类型可以是有符号或无符号。如果程序的一个翻译单元包含不能由任何允许的类型表示的整数文本，则该程序是格式错误的。

这些是标准中整数的升级规则。

4.5整体促销[conv.prom]

如果int可以表示源类型的所有值，则除bool、char16\u t、char32\u t或wchar\u t以外的整数类型的PR值（其整数转换秩（4.13）小于int秩）可以转换为int类型的PR值；否则，可以将源prvalue转换为类型为unsigned int的prvalue。

Answer 3

-2147483648不是数字。C语言不支持负值。

-2147483648实际上是一个表达式：一个正文本值2147483648，前面有一元-运算符。值2147483648对于平台上int范围的正面来说显然太大。如果类型long int在您的平台上具有更大的范围，则编译器必须自动假定2147483648具有long int类型。（在C 11中，编译器还必须考虑<代码> long long int /Cux>类型）。这将使编译器在较大类型的域中计算-2147483648，结果将是负数，正如人们所期望的那样。

但是，显然在您的情况下，long int的范围与int的范围相同，并且通常在您的平台上没有大于int范围的整数类型。这正式意味着正常量2147483648溢出所有可用的有符号整数类型，这反过来意味着程序的行为未定义。（语言规范在这种情况下选择未定义的行为，而不需要诊断消息，这有点奇怪，但事实就是这样。）

实际上，考虑到行为是未定义的，2147483648可能被解释为某个依赖于实现的负值，该负值在应用一元-后恰好变为正值。或者，一些实现可能会决定尝试使用无符号类型来表示值（例如，在C89/90中，编译器需要使用无符号长整型，但在C99或C中则不需要）。实现可以做任何事情，因为行为是未定义的。

作为旁注，这就是为什么像INT\u MIN这样的常量通常被定义为

#define INT_MIN (-2147483647 - 1)

而不是看起来更直截了当的

#define INT_MIN -2147483648

后者不会如预期的那样发挥作用。