为何int取INT_MIN时(-n)/2为正？n与INT_MIN运算差异解析

先直接点出核心：有符号整数溢出在C++中属于未定义行为（Undefined Behavior, UB），这是C++标准明确规定的，不是编译器特有的“特性”——编译器可以自由选择如何处理这种情况，这也是你看到各种奇怪结果的根本原因。接下来我们逐个拆解你的疑问：

为什么-n/2（f）的结果是正数？ #

你提到运算符优先级是一元负号高于除法，理论上应该先算-n再除以2，但这里的关键是：-n本身是有符号整数溢出（n是INT_MIN，它的相反数是2³¹，超过了int的最大值2³¹-1），属于UB。编译器不需要严格按照“先计算-n再除以2”的步骤执行，而是可以做等价的表达式优化。

从数学上看，-n/2完全等价于-(n/2)——而n/2是INT_MIN除以2，结果是-1073741824（因为INT_MIN是偶数，整除后正好是这个值），那么-(n/2)就是1073741824，这是一个合法的int值（远小于INT_MAX）。编译器选择了这个更安全、更高效的优化路径，直接跳过了会触发溢出的-n计算，所以得到了正数结果。

为什么(-n)/2（g）和-n/2结果一致？ #

同样是因为-n的溢出是UB。编译器并没有真的先计算出-n（也就是按照补码环绕得到n本身），而是把整个表达式(-n)/2当作数学上的(2³¹)/2来计算，结果是2³⁰=1073741824，这个值可以被int正常容纳，所以输出正数。

为什么(-INT_MIN)/2（h）结果是负数？ #

这里的区别在于INT_MIN是编译期常量，-INT_MIN是一个常量表达式。编译器在编译时就能检测到这个表达式会溢出，并且很多编译器（比如你的g++）会按照补码环绕的规则来处理常量表达式的溢出：-INT_MIN被直接转换为INT_MIN本身（因为2³¹的补码表示就是INT_MIN），然后除以2自然得到-1073741824。同时编译器会给出-Woverflow警告，提示你这个表达式存在溢出风险。

n和INT_MIN的核心差异？ #

• int n = 1<<31;这行代码本身就是UB：C++标准规定，有符号整数左移导致符号位变化是未定义行为。虽然大多数编译器会把它处理成INT_MIN，但标准不保证这一点——换个编译器或优化级别，n的值可能完全不同。
• INT_MIN是标准库定义的合法常量，是32位int能表示的最小值，不存在UB问题。

编译器对变量表达式（比如n相关的计算）和常量表达式（比如INT_MIN相关的计算）的优化策略不同：对于变量，编译器更倾向于做数学上的等价优化（避免溢出，生成更高效的代码）；对于常量表达式，编译器会在编译期直接计算，可能更严格地按照补码规则处理溢出（同时给出警告）。

总结 #

所有这些奇怪的结果，根源都是有符号整数溢出是UB。C++标准没有规定编译器必须如何处理这种情况，所以你看到的行为是编译器在优化和溢出处理之间做出的选择。如果想要避免这类问题，建议：

• 避免直接操作有符号整数的极值，必要时使用无符号整数（unsigned int）来处理这类计算，因为无符号整数的溢出是定义良好的（按模2^N环绕）。
• 开启编译器的溢出警告（比如-Woverflow），提前发现潜在的UB。

内容的提问来源于stack exchange，提问作者user1079505