C语言int类型整数加法溢出结果取值的底层原理

计算结果和预期不符的核心原因是对有符号整数的编码规则存在认知偏差：推导时默认使用了早已被硬件淘汰的原码（符号-幅值码）规则，但所有通用商用CPU的有符号整数都采用二进制补码编码，加法电路也完全基于补码逻辑设计。

补码的位权规则：最高位不是单纯的符号标记 #

原码的规则确实是最高位仅作正负标记，剩余位直接表示数值大小，还会存在+0和-0两个零值，运算时需要单独处理符号位，电路实现效率极低，从来没有在通用CPU的整数运算单元中实际应用。
补码的每一位都有固定的数值权重，不存在独立于数值之外的“纯符号位”，32位补码的位权规则非常明确：

• 低31位（从右数第0位到第30位）的权重和无符号整数完全一致，依次为2^0、21……2^30
• 最高位（第31位，也就是常规认知里的符号位）的权重是 -2^31，也就是固定值-2147483648

所有实测结果都可以直接用这个权重规则算出：

• 2000000000 + 2000000000 = 4000000000，这个和值对应的32位二进制位模式按补码权重计算时，由于4000000000 > 2^31（2147483648），最终值 = 4000000000 - 2^32（4294967296）= -294967296，和实际运行结果完全一致。
• 推导预期的-1852516352是原码规则下的结果：即把最高位的2^31权重直接丢弃，剩余值加负号，这个结果在补码体系下不可能出现。

硬件加法的实现逻辑：不区分数值符号，统一按无符号进位计算 #

观测到的“参与相加的数值越大，溢出后的结果也对应增大”的规律，本质上来自CPU整数加法电路的实现逻辑：

• 加法电路根本不会识别操作数是有符号数还是无符号数，只会对两个32位二进制数做逐位进位加法，超出第32位的进位值直接丢弃，最终输出固定的32位位模式。
• 对同一个输出位模式，按无符号整数规则解读，结果就是两数之和对2^32取模的值；按补码有符号规则解读，就是看到的有符号运算结果。
• 运算过程中不存在“加到2^{31就切换到负数逻辑”的特殊处理：当累加值达到2}31时，对应的位模式是10000000 00000000 00000000 00000000，按补码规则解读这个值就是-2147483648，根本不存在原码规则下的-0，后续剩余的累加值直接和这个值做普通加法即可，也就是实测匹配的-2147483648 + 1852516352 = -294967296计算过程。

C语言标准层面的补充说明 #

从C语言标准的正式规定来看，有符号整数溢出属于未定义行为，标准不强制要求编译器必须输出补码回绕的结果。但目前所有主流的x86、ARM、RISC-V架构都采用补码存储整数，加法电路也统一实现为模2^n回绕逻辑，因此实际测试中会稳定观测到上述计算结果，不会出现随机值。

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