shifttoomanybits检测位移量≥左操作数类型位宽的未定义行为，依据c11标准6.5.7节，cppcheck将其报告为error/warning级问题，如int x=1; x
会触发未定义行为（UB），编译器不保证结果一致，实际值取决于编译器实现、优化级别和目标平台。
cppcheck 报 shiftTooManyBits 就是这个原因
当右操作数（位移量）≥ 左操作数类型提升后的位宽时，cppcheck 的 CheckType 检查器会报告 shiftTooManyBits。这不是警告风格问题，而是 C/C++ 标准明确定义的未定义行为（C11 6.5.7 节）。例如：
int x = 1 ：32 位 <code>int上，位移 32 位及以上 → UBunsigned short y = 1; y ：16 位类型位移 16 位 → UB（不是 15）long long z = 1; z ：64 位类型位移 64 位 → UB（不是 63）
注意：cppcheck 的判断依据来自平台配置的 int_bit、long_bit、long_long_bit，不是硬编码，所以跨平台检查时必须配对平台描述文件。
1 和 <code>1 行为可能完全不同
同一个表达式，是否用变量控制位移量，会导致编译器生成完全不同的机器码：
int i = 35; int j = 1 ：在 x86 上，CPU 的 <code>shl指令自动对位移量做& 0x1F（32 位）或& 0x3F（64 位），所以实际执行的是1 → 结果为 <code>8int j = 1 ：常量折叠阶段，编译器发现 35 ≥ 32，直接设为 <code>0（GCC/Clang 常见行为）- 开启
-O2后，两者都可能被优化为0，但未定义行为本身未消除
这意味着：依赖“运行时变量位移”来绕过溢出检查是危险的，它掩盖了 UB，而非修复它。
不同整型的位宽陷阱：别只看 sizeof
sizeof(int) 是 4 字节 ≠ int 有 32 位可安全位移 —— 实际可用位移范围是 [0, bits - 1]，而 bits 来自平台定义：
-
int在多数系统是 32 位，但标准只要求 ≥16 位；short可能是 16 或 32 位 -
char移位前会整型提升为int，所以char c = 1; c 实际是 <code>int位移 31，不是char位移 -
long long通常是 64 位，但位移 64 仍 UB；要安全左移 63 位，得用unsigned long long并确保值 ≤ 1
最稳妥的方式是显式检查：if (shift >= std::numeric_limits<decltype>::digits) { /* handle error */ }</decltype>，其中 digits 是无符号位数（不含符号位）。
为什么 unsigned 也不能豁免
很多人误以为“无符号就没符号问题，位移就安全”，但标准明确规定：对任意整型（包括 unsigned），若位移量 ≥ 类型位宽，仍是未定义行为。
unsigned int u = 1; u → UB，不是“等于 0”或“循环”- 它不等价于
u * (1U ，后者本身也溢出（<code>1U 就已 UB） - 唯一真正安全的替代是
std::bitset或手动拆分逻辑（如用if (shift >= 32) { result = 0; }）
真正容易被忽略的点是：UB 不仅影响结果值，还可能让编译器在优化时彻底删除分支、重排逻辑，甚至导致整个函数被内联后产生静默错误 —— 它不是“输出错”，而是“程序语义崩塌”。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
