C语言中左移操作里整数字面量后缀UL的作用探究

先看你提到的这个Linux内核中常见的宏：

#define test_bit(n, flag) (1UL << (n) & (flag))

你疑惑左移操作为何还要加UL后缀，其实这个后缀是为了规避三个关键问题：

• 杜绝有符号整数溢出的未定义行为
  C标准明确规定：有符号整数左移后结果超出其类型取值范围时，属于未定义行为。比如32位系统中，1是int类型（有符号），当n=31时，1 << 31的结果会超过int的最大值（2^31-1），编译器可以任意处理这个情况——可能输出错误值，甚至触发奇怪的优化逻辑。而1UL是无符号长整型，只要n不超过unsigned long的位数（32位或64位，随平台变化），左移结果都是确定合法的，完全没有未定义行为的风险。

• 避免符号扩展破坏按位与的结果
  假设flag是unsigned long类型，如果用1（int）左移，当移位后得到负数（比如32位int下1<<31是负数），在和unsigned long的flag做运算时，这个负数会被符号扩展：高位全部补1，变成一个高位全1的无符号数。这时候按位与操作就会错误地把flag的高位也纳入判断，导致测试结果完全错误。用1UL的话，整个表达式都以无符号长整型运算，不会出现符号扩展，掩码只会精准定位到目标位。

• 适配多平台的位数差异
  Linux内核要兼容32位、64位等各种平台，unsigned long的位数会随平台自动调整（32位平台是32位，64位是64位）。1UL能保证生成的掩码长度和flag的类型长度完全匹配，不管平台位数是多少，都能正确生成对应位置的测试掩码，不会因为平台变化出现移位越界或者掩码长度不足的问题。

举个实际场景：32位系统中，1 << 31作为有符号int是负数，转换成64位unsigned long时会变成0xFFFFFFFF80000000，和flag按位与时会错误地检查高32位；而1UL <<31在32位系统是0x80000000，64位系统是0x0000000080000000，都是精准的目标位掩码，测试结果完全正确。

内容的提问来源于stack exchange，提问作者Feng. Ma