UBSan在运行时捕获有符号整数溢出等未定义行为并导致进程崩溃，而非编译错误；该报错通常暴露算术表达式缺乏前置范围校验等逻辑缺陷。
看到runtime error: signed integer overflow这类报错，说明UBSan已捕获到未定义行为，不是编译失败，而是运行时报错
UBSan不拦在编译阶段，它是在程序执行到出问题那行时才中断并打印错误。所以你看到的不是警告或编译错误，而是进程直接崩溃（除非你配了-fno-sanitize-recover或-fsanitize-trap）。关键不是“怎么让编译过”，而是“哪一行触发了UB，为什么合法代码会触发它”。
signed integer overflow最常见，但别急着加unsigned或改算法
有符号整数溢出（比如INT_MAX + 1）是UBSan默认检查项，但它往往暴露的是逻辑缺陷，而非单纯数值越界：
- 算术表达式没做前置范围校验，比如用
size_t索引却存进int变量 - 循环计数器用
int i = 0; i ，但<code>n可能大于INT_MAX - 指针差值计算（
p - q）结果超出int表示范围，而你把它赋给了int - 宏或模板推导隐式转成
int，实际应为long long
示例：int k = 0x7fffffff; k += 1; → 报错。修复不是改成unsigned int，而是确认此处是否真需要有符号语义；若需大范围，应改用long long或加边界检查。
Clang 22.1.3
下载
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
报错行没显示完整调用栈？补UBSAN_OPTIONS=print_stacktrace=1
默认UBSan只打触发点那一行，容易误判上下文。必须加环境变量才能看到谁调用了它：
- 运行前设置：
UBSAN_OPTIONS=print_stacktrace=1 ./myapp - 配合
-g编译，否则栈帧里只有地址，没有函数名和行号 - 如果用IDE（如Xcode、CLion），在Run Configuration里把
UBSAN_OPTIONS设为环境变量，别漏掉 - 注意：Clang 15+默认启用
print_stacktrace，但旧版本或某些交叉编译链仍需显式开启
误报或第三方库报错？用__attribute__((no_sanitize("undefined")))临时绕过
UBSan只检查**运行到的代码**，所以不能靠“加了就万事大吉”——它不查没执行的路径，也不该查你不控制的库：
- 对已知安全的内联函数或性能敏感代码段，加
__attribute__((no_sanitize("undefined")))禁用插桩 - 全局抑制用
suppressions=ubsan.supp文件，格式为undefined:<code>path/to/file.cc:line，但仅限确认是误报时用 - 不要用
-fno-sanitize=undefined关全局，那等于关掉整个检测；要关就关具体子项，比如-fno-sanitize=shift - 虚幻引擎或嵌入式项目（如SF32LB52）中，部分底层驱动代码可能依赖UB（如强制类型转换），此时必须局部禁用，而非妥协整个工程
真正难的不是让UBSan跑起来，而是判断报错是代码缺陷、平台特性，还是构建链本身的限制——比如某些裸机环境不支持UBSan运行时库，这时候报错可能来自链接阶段缺失libclang_rt.ubsan_standalone，而不是你的C++逻辑有问题。
