为何0xffffffff+1与4294967295+1赋值给unsigned long long结果不同？

核心原因是C语言对十进制整数常量和十六进制/八进制整数常量的类型匹配规则不一样，具体细节如下：

1. 十进制常量（如4294967295）的类型匹配逻辑 #

十进制常量会按以下优先级尝试匹配类型：

• 优先使用int，只要值在int的范围内就用该类型；
• 若超出int范围，尝试long int；
• 仍超出的话，最终匹配long long int。

在你的32位环境中：

• int的取值范围是-2147483648 ~ 2147483647，4294967295明显超出这个区间；
• 若long int同样是32位，范围和int一致，也容纳不下该值；
• 因此4294967295会被识别为long long int（64位类型），4294967295 + 1的计算在64位空间进行，结果为4294967296，赋值给unsigned long long后输出符合预期。

2. 十六进制/八进制常量（如0xffffffff）的类型匹配逻辑 #

十六进制、八进制常量的匹配逻辑更偏向无符号类型，优先级顺序为：

• 先尝试int，值在范围内则使用；
• 超出int范围时，尝试unsigned int；
• 仍超出的话，依次匹配long int、unsigned long int、long long int、unsigned long long int。

在你的32位环境中：

• 0xffffffff的值恰好等于32位unsigned int的最大值4294967295，因此直接被识别为unsigned int；
• 0xffffffff + 1触发32位无符号整数溢出（无符号溢出是标准定义的合法行为，结果取模2^32），得到0，后续赋值给unsigned long long后输出自然为0。

验证代码中的其他例子 #

• 0xfffffffe + 1：0xfffffffe的值为4294967294，小于32位unsigned int的最大值，因此匹配为unsigned int，加1后得到4294967295，赋值给unsigned long long后输出正确；
• 0xfffffffff + 1：该十六进制值为2^40 -1，远超32位unsigned int和long int的范围，所以匹配为long long int，加1后得到2^40，输出符合预期。

解决方法 #

如果想让十六进制常量按64位类型计算，直接给常量添加ULL后缀，强制指定为unsigned long long类型：

unsigned long long resTestFixed = 0xffffffffULL + 1;
// 此时计算在64位空间进行，结果为4294967296

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