Win32 InterlockedIncrement()是否正确支持有符号整数溢出？

1. 你没误解C语言的有符号溢出规则 #

C标准清晰定义：有符号整数溢出属于未定义行为（UB）。这不是说溢出一定会出问题，而是编译器完全有权对这类代码做任意处理——从生成补码回绕的结果，到直接删除相关代码，甚至触发程序异常，都符合标准。你测试里((LONG)1) + INT_MAX得到INT_MIN，只是GCC在默认编译配置下的行为，若开启-fstrict-overflow这类优化选项，结果可能完全不同。

2. Windows的Interlocked系列API有独立的行为约定 #

InterlockedIncrement是Windows提供的底层原子操作，它的行为不受C语言标准约束。Windows官方明确规定，这类原子函数处理有符号整数溢出时，会按照补码回绕的逻辑执行，也就是你看到的INT_MAX加1后得到INT_MIN的结果。这是平台层面的硬约定，和C语言的UB规则不冲突——因为API直接封装了CPU的原子指令，绕过了C编译器的优化逻辑。

3. 补码普及不代表UB问题只是理论 #

现在主流系统确实都用补码存储有符号整数，但这不意味着可以无视有符号溢出的UB：

• 编译器优化风险：编译器会利用UB规则做激进优化。比如代码里的if (x + 1 > x)，编译器会直接判定这个条件永远为真（因为标准假设不会发生溢出），进而删除整个判断逻辑，导致程序逻辑出错。
• 跨平台隐患：虽然当前大部分平台是补码，但特殊嵌入式系统或未来架构可能有例外，依赖补码回绕的代码在这些场景下会直接崩溃。
• 代码可维护性：依赖UB的代码存在隐含假设，其他开发者接手时很难快速理解，容易引入bug。

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