① 钩子一个数学上恒真的表达式被编译成恒 1x 1 x—— 数学上只有当x INT_MAXx1溢出时才为假其余恒为真。但在-O2下编译器把它编译成了movl $1, %eax; ret——无条件返回 1。即使你传入INT_MAX它也返回 1。因为有符号溢出是未定义行为UB。编译器假设你的程序永远不触发 UB于是认为x1不会溢出 → 恒真直接折叠成常量。这一集把UB 的代价钉在汇编上编译器不是坏了而是信任你没写 UB然后按这份信任激进地重写你的代码。② 源码 vs 汇编对照__attribute__((noinline))intoverflow_never(intx){returnx1x;// 有符号溢出 UB}__attribute__((noinline))intshift_far(intx){returnx33;// 移位量 ≥ 类型位宽 UB}__attribute__((noinline))intderef(int*p){return*p1;// 空指针解引用 UB}-O2下三个函数的汇编本机 g 15.2.0 实测overflow_never(int): movl $1, %eax ; 折叠成恒 1x1 的加法整个消失了 ret shift_far(int): xorl %eax, %eax ; 编译器判定结果恒为 0 ret deref(int*): movl (%rcx), %eax addl $1, %eax ret运行时证据-O2实跑overflow_never(INT_MAX) 1 ; 数学上应为假但溢出是 UB → 编译器当它不发生 shift_far(1) 0 ; 133 是 UB → 编译器给了个随便的结果 0 deref(y) 42 ; 正常指针正常结果加上-fsanitizeundefined后插桩立现汇编证据; overflow_never 被折叠成常量后UBSan 反而无处插桩——常量折叠先于插桩发生 overflow_never(int): movl $1, %eax ret ; shift_farUBSan 插入了移位越界检查 shift_far(int): movl $33, %r8d movslq %ecx, %rdx leaq .Lubsan_data2(%rip), %rcx call __ubsan_handle_shift_out_of_bounds ; ← 拦截 xorl %eax, %eax ret ; derefUBSan 插入了空指针 对齐 加法溢出三重检查 deref(int*): testq %rcx, %rcx je .L5 ; 空指针 → __ubsan_handle_type_mismatch_v1 testb $3, %cl jne .L5 ; 未对齐 → 同上 .L6: movl (%rax), %eax addl $1, %r9d jo .L15 ; 溢出 → __ubsan_handle_add_overflow ret诚实备注MinGW ucrt64 的 g 不带libubsan运行时本机-fsanitizeundefined能编译出插桩汇编、但链接 .exe 会报cannot find -lubsan。Linux 发行版 g 自带该运行时可完整链接运行并打印报错。汇编层面的插桩证据在本机已验证。③ 为什么这么设计未定义行为 编译器获得的最大授权标准对 UB 的表述是行为无约束。编译器利用这点做激进假设——因为合法程序里 UB 不会发生所以它可以放心折叠、删除、重排任何仅当 UB 时才成立的代码。overflow_never的原理x1 x在不溢出的域内恒真溢出是 UB编译器假设不存在。于是整个表达式折叠为 1x1的加法被删掉——即使你传INT_MAX进去也没有溢出发生因为它根本没算加法。shift_far的原理x 33对 32 位 int 是 UB。编译器可以随便处理——它选了个结果 0。不是硬件会怎样而是UB 范围内编译器可以给任何答案。UB 清单部分有符号溢出、移位量 ≥ 位宽、空指针/越界解引用、悬垂引用、除零、未初始化读取、数据竞争……本集演示了前三类。为什么 UBSan 能救你-fsanitizeundefined在优化前把检查插进 IR让假设变成运行期验证——触发 UB 时跳到处理函数报错而不是悄悄给出任意结果。注意overflow_never因常量折叠太早没被插桩这本身就是优化先于检查的注脚。真实事故历史上大量漏洞如 Linux 内核-fno-strict-overflow、CVE 里空指针检查被删除导致提权都源于编译器利用 UB 删除无意义检查。安全上已普遍用-fwrapv/-fno-strict-aliasing等方式关掉部分激进假设。④ 深入一UB 的三种结果形态触碰 UB 后程序可能表现为静默错误结果本集overflow_never/shift_far返回任意值程序继续跑——最阴险因为看起来正常优化删除安全检查真实漏洞模式编译器把空指针检查当永假删掉 → 后续解引用崩溃/提权跨编译单元/平台漂移-O0正常、-O2反转、换 clang 又不同——UB 程序没有稳定行为可依赖。为什么是这三种编译器只承诺无 UB 程序的行为UB 程序在任何优化决策下都可能被任意改写所以三种形态都可能出现且无法预测哪个出现。⑤ 深入二为什么优化删除安全检查是真实漏洞考虑voidf(int*p){if(pnullptr)return;// 空指针检查*p42;// 解引用}若编译器先看到*p 42并证明按 UB 假设p非空它可能把空指针检查当成永假而删除——因为如果 p 为空*p42 已经是 UB前面的检查毫无意义。这就是UB 让防御性代码失效的机器级原理也是大量 CVE 的根因。教训不要用先检查后使用来防御 UB——编译器可能认为检查多余。要在根源上保证不产生 UB边界检查在写入前、指针一定有效或靠 sanitizer 兜底。⑥ 常见误区误区 1“UB 只是结果不确定”不是——UB 是整个程序行为无约束可能在任何编译档/编译器下以任何方式失败包括看起来正常。误区 2“我在 -O0 下测过没问题”UB 程序在-O0正常、-O2反转是常态本集就是-O0会真的算x1。误区 3“溢出就溢出反正是二补数”有符号溢出是 UB无符号溢出才是定义行为回绕。二补数只约束无符号。误区 4“UBSan 能抓所有 UB”UBSan 抓运行期可观测的 UB常量折叠后消失的如overflow_never它无处插桩——它抓的是真发生的。误区 5“volatile能防止 UB 优化”volatile 只影响对该变量的访问不改变表达式本身是 UB的事实。UB 的优化权利在 IR 层volatile 挡不住。误区 6“无符号溢出也要小心”不用——无符号溢出是定义行为回绕编译器必须保留。只有有符号溢出、移位越界、解引用等才是 UB。溢出UB的直觉只对有符号成立。⑦ 实战启示开-Wall -Wextra -Werror编译器自己会警告明显的 UB如x 33直接警告left shift count width。用 UBSan / ASan 做开发期检测-fsanitizeundefined,address能在运行期抓到溢出/空指针/越界成本远低于线上事故。理解编译器完全信任你写代码时以优化器视角自问——这段代码在永不触发 UB的假设下会被怎样改写不要依赖我机器上跑得好好的UB 程序在-O0可能正常、-O2反转、换个编译器又不同——结果不可预测正是 UB 的惩罚。写防御性代码要在根源保证不要靠先检查后使用补 UB编译器可能删检查用索引边界、std::optional、span带界从源头避免 UB。⑧ 扩展专题一无符号溢出 vs 有符号溢出的汇编差异无符号unsigned溢出有定义模 2^32 回绕——编译器必须保留回绕语义有符号溢出UB——编译器可以当作不发生折叠/假设。unsignedu_inc(unsignedx){returnx1;}// 定义良好回绕ints_inc(intx){returnx1;}// UB若 xINT_MAX汇编u_inc必须有addl $1回绕是语义的一部分s_inc的x1 可能溢出让编译器在需要溢出前先判断的写法如x1 x里随意假设。这就是同样一行加法无符号要守着、有符号能放飞的机器级区别。⑨ 扩展专题二-fwrapv与关掉 UB 假设的代价-fwrapv告诉编译器有符号溢出按回绕处理把 UB 变成定义行为——编译器不再做溢出不会发生的假设代价可能丢失依赖该假设的优化如x1 x不再折叠成 1收益行为更可预期遗留代码/内核这类必须稳妥的软件常开。抉择日常应用不必开-fwrapv靠 sanitizer 正确性保证只有不能容忍 UB 任意结果的底层软件才需要。理解它 理解优化授权与稳定性的取舍。⑩ 扩展 FAQQINT_MAX1在-O0下真的算吗A-O0通常真的执行加法结果按二补数回绕但这是实际行为不是定义行为-O2可能直接按 UB 假设给出任意值。同一个 UB不同档位不同命运。QUBSan 和 ASan 区别AUBSan 抓未定义行为溢出、移位越界、空指针等ASan 抓内存错误越界、use-after-free。两者互补常一起开。Q数据竞争是 UB 吗A是E16/E17 讲过。多线程 UB 最麻烦——sanitizer 用 TSan 抓。Qreinterpret_cast会制造 UB 吗A合法使用按对象真实类型访问不 UB把 int* 当 float* 读写违反严格别名 UB。memcpy/bit_cast是安全替代。Q公司代码要不要全开 sanitizerA开发/CI 强烈建议生产环境视性能预算sanitizer 有开销。至少测试与 CI 必须开。⑪ 扩展实验三档对比E20_ub.cpp用-O0/-O1/-O2 -S看overflow_never何时从真算变折叠成 1。UBSan 插桩-O2 -fsanitizeundefined -S对照shift_far/deref的插桩调用点。-fwrapv对照-O2 -fwrapv -S看x1 x是否恢复成真实比较。无符号对照写u1 u无符号-O2 -S确认不折叠回绕语义被保留。空指针删除演示写先检查后使用-O2看检查是否被删真实漏洞模式。⑬ 扩展专题三UBSan 插桩的时机——为什么有的 UB 抓不到overflow_never在 UBSan 下没有插桩仍被折叠成movl $1——这不是 bug是顺序编译器先做常量折叠/优化把x1 x折叠成 1折叠后的代码里已经没有溢出操作可检查了UBSan 只能在优化后仍存在的操作上插桩。所以 UBSan 是补充不是兜底它抓运行期真会执行到的 UB抓不到被优化提前消除的 UB。这就是为什么别依赖任何单一工具用 -Wall sanitizer 代码审查 三层。⑭ 扩展专题四未初始化读取——UB 的最隐蔽形态intf(){intx;returnx1;}// x 未初始化 UB-O0可能碰巧读栈上残留值-O2下编译器可以假设 x 有某个值进行优化——结果同样不可预测为什么隐蔽没有明显爆点不崩、不越界只是结果偶尔不对怎么抓MSanMemorySanitizer专抓未初始化读取-Wmaybe-uninitialized能提前警告。机器级本质未初始化变量 “编译器可以自由选择假设其值的许可证——和shift_far一样属于UB 范围内给任意答案”。所有变量初始化是让编译器可预测的第一步。⑮ 扩展 FAQ第二轮Qstd::optional能避免未初始化吗A能——optional 把是否有值变成类型的一部分读取空 optional 是定义好的抛bad_optional_access不是 UB。用类型表达状态比可能未初始化的裸变量安全。Q为什么编译器不帮我检查溢出A检查要钱每条加法都判断 jo编译器默认程序合法无需检查。这就是 UBSan 存在的原因——开发期你要检查发布期你要快两者分开。Q-fsanitizeaddress能抓 UB 吗A不能——它抓内存错误越界/UAF不抓溢出/移位。两个 sanitizer 语义不同按需组合。Q第三方库里有 UB 怎么办A能用 sanitizer 跑它的测试最好不能就假设它内部可能有 UB但别让它接到你的 UB 输入上边界校验。QUB 和implementation-defined区别AUB 是行为无约束implementation-defined 是实现必须给出明确行为并文档化如sizeof(int)。后者可预期、可查文档前者不可预期。⑯ 扩展实验第二轮未初始化演示-O0vs-O2跑未初始化读取观察结果变化UB 漂移的直接证据。-Wmaybe-uninitialized开-Wall -Wextra看编译器是否警告初始化后再编译对比。optional 对照std::optionalint读取空值确认是定义行为抛异常而非 UB。MSan 说明在支持环境用 MemorySanitizer 抓未初始化读取gcc 下可先读文档/用 clang。-fno-strict-aliasing对类型双关代码开/关该选项看优化差异与结果漂移。⑱ 扩展专题五如何写出让编译器无法误解的代码UB 的根源是编译器从你代码推断出的假设可能错误。要让推断正确从源头消除歧义初始化一切变量未初始化 自由假设许可证用边界安全容器std::vector::at/span/迭代器代替裸指针下标越界 UB用定义良好的运算需要回绕就用unsigned/uint64_t需要饱和就手写分支别指望溢出自然用std::optional/std::variant表达可能没有值比哨兵值/裸空指针更明确避免类型双关用memcpy/std::bit_cast而非reinterpret_cast读不同类型。每一条的机器理由都在让编译器相信的假设与你的真实意图一致——一致它放心优化不一致它按错误假设重写。UB 的终极解药不是更小心而是用类型和容器让 UB 无从发生。⑲ 扩展专题六UB 与未指定行为的边界标准里容易混淆的三种类别含义例子编译器能做什么未定义行为行为无约束有符号溢出任意重写/删除/假设未指定行为实现从若干选择中选一个但必须一致求值顺序合法地选一种但不会崩溃implementation-defined实现必须文档化sizeof(int)、char 是否有符号有文档、可查、可预期为什么区分重要UB 是别依赖任何结果都可能未指定/实现定义是有约束的变体可查文档。把UB 恐惧扩散到未指定行为是过度谨慎——后者是可预期地选择。⑳ 扩展 FAQ第三轮Qstd::span能防越界吗A它带界信息配合at()/边界检查可防越界但operator[]仍不检查要快。span 的价值是让越界有地方检查而非自动防。Q生产代码能开-fwrapv吗A能行为更可预期但要接受依赖溢出折叠的优化丢失。大多数应用用 sanitizer 而非-fwrapv。Q为什么x1 x这种常识会被优化A因为编译器按无 UB建模而x1在有符号下溢出即 UB——常识只在无符号/数学整数成立C 有符号整数不是数学整数。QINT_MIN / -1是 UB 吗A是——结果2^31无法用 int 表示除法溢出是 UB。边界值要显式处理。QUBSan 在生产能开吗A开销小大多数检查很轻但仍有。常用做法CI/测试开 UBSanASan生产用无 sanitizer 边界审查。Qx 31恰好等于位宽-1算 UB 吗A不算移位量 位宽但若左移使符号位变 1 属有符号溢出风险具体看后续运算。移位量的 UB 边界是≥ 位宽符号位问题另算。㉑ 扩展实验第三轮INT_MIN/-1演示-O2下除以 -1 的汇编与结果确认 UB 漂移。memcpyvsreinterpret_cast类型双关两种写法-O2 -fstrict-aliasing对比是否被优化出反直觉结果。span 越界std::span越界读对比有检查与无检查的两种访问。求值顺序写顺序相关的表达式未指定行为-O2确认编译器合法地选择一种。bit_cast 替代把reinterpret_cast双关改成std::bit_cast确认定义良好且同样高效。-fsanitizeaddress对照越界读触发 ASan 报错路径 vs UBSan 的差异ASan 管内存UBSan 管语义。㉒ 扩展专题七UB 与安全的最后一公里UB 不只是性能问题更是安全边界问题攻击者常利用UB 导致的安全检查被删除提权CVE 经典模式现代防御-fstack-protector、ASLR、PIEE04 提过、sanitizer 进 CI写安全代码 写无 UB 代码 用类型消除边界歧义。为什么安全审查要懂汇编很多漏洞在源码层看不见编译器删除检查后才有问题只有看.s/.exe才能确认检查还在不在。本系列教你看汇编的终极价值之一能判断优化是否偷走了你的防御。㉓ 扩展 FAQ第四轮Q-fno-strict-overflow和-fwrapv一样吗A不完全一样。-fwrapv强制回绕语义结果可预期-fno-strict-overflow只是别做依赖无溢出的优化更宽松。底层软件常用后者保兼容。Qstd::numeric_limitsint::max()判断溢出可以吗A可以——在相加之前用x max - y判断无 UB相加之后判断就晚了。判断要在可能 UB 的操作之前做。Q为什么memcpy比reinterpret_cast双关更安全Amemcpy逐字节拷贝是定义良好的任何对象可拷贝到字节数组再拷回reinterpret_cast读不同类型违反严格别名。两者通常编译成同样的mov但语义上一个安全一个 UB。㉔ 扩展实验第四轮溢出前判断写x max - y的版本 vsx y max的版本-O2 -S对比后者是 UB 陷阱。-fstack-protector开/关编译同一函数反汇编看栈 canary 是否插入安全防御的机器形态。-fno-strict-overflow对照对overflow_never开/关该选项看x1x是否恢复真实比较。CVE 模式复现写空指针检查 解引用的典型函数-O2看检查是否被删理解漏洞根因。无 UB 重构把本集三个 UB 函数重写成无 UB 版本溢出判断/移位检查/可选指针确认语义正确且仍被优化。㉕ 悬念编译器在-O2下无所不能可为什么一个 64MB 的数组换个遍历顺序就能差 5 倍优化的尽头真正的瓶颈早已不在指令里而在 CPU 的缓存和内存层次。