Undefined Behavior

未定义行为（Undefined Behavior，UB）是指：C/C++ 语言标准对程序在某些情况下的行为不施加任何要求。 也就是说，当程序执行触发 UB 时，语言标准不再保证程序会产生什么结果，程序的行为是不可预测的。程序可能正常运行、得到错误结果、崩溃，也可能由于编译器优化而表现出完全出乎意料的行为。

UB 和函数的前置条件很像。一个函数文档写着"参数不能为空"，函数调用者传入 NULL，作者没有义务让它返回错误码或抛异常，因为调用方违反了前置条件。UB 就是语言层面的前置条件：程序员承诺"我的程序永远不会走到 UB"，编译器则据此放手优化。

可以把避免 UB 理解为程序必须满足的一组隐含前置条件。 编译器不会在运行时检查或强制这些条件成立，甚至还会在优化时假设它们成立。如果程序实际违反了这些前置条件，就超出了语言标准所保证的行为范围，因此编译器不必为这种情况保留任何特定的执行结果。

例如：

bool f(int x) {
    return x + 1 > x;
}

C/C++ 规定有符号整数溢出是 UB。因此，编译器可以假设 x + 1 不会溢出，进而推导出 x + 1 > x 恒为真，将函数直接优化为 return true;。但如果实际传入 INT_MAX，程序就违反了这个隐含前置条件，触发 UB。此时，编译器既不需要检测溢出，也不需要保证比较表达式按照某种特定方式执行。

C/C++ 将某些行为定义为 UB，核心原因是：它们选择把一部分安全性责任交给程序员，以换取更低的运行时开销、更大的编译器优化空间，以及对底层硬件更直接的控制。

但这里有一个很重要的区别：UB 不仅仅意味着“不检查错误”，还意味着编译器可以假设这种错误永远不会发生。 后者其实是理解 UB 的关键。

先看数组越界。Java 中，数组是一个携带长度信息的对象。执行 a[i] 时，运行时能够知道数组长度，并保证越界会抛出异常。JIT 编译器如果能证明索引合法，也可以省略实际的边界检查。但在 C 中：

void f(int *p, int i) {
    p[i] = 42;
}

p 只是一个指针。函数并不知道它指向的对象有多大，甚至不知道它是否还有效。如果要求像 Java 一样保证所有非法访问都能被检测出来，就需要在运行时跟踪指针指向的对象、对象大小、生命周期等信息。这可能涉及额外的元数据、检查指令、内存分配机制乃至 ABI 的改变。

而且硬件的内存保护也无法解决所有问题。例如，数组越界访问到同一块已分配内存中的其他对象，操作系统通常不会产生异常。所以，对 C/C++ 而言，完整的内存安全检查不只是多加一个 if 那么简单，而是可能改变整个语言的运行时模型。

不过，这还不是 UB 最重要的作用。考虑下面的 C++ 代码：

bool f(int x) {
    return x + 1 > x;
}

假设 int 是 32 位整数。如果 x == INT_MAX，那么 x + 1 会发生有符号整数溢出。在 Java 中，int 溢出被明确规定为回绕，因此 INT_MAX + 1 会得到 INT_MIN，这个比较就会返回 false。注意，Java 对普通整数溢出并不会自动抛异常。

但在 C/C++ 中，有符号整数溢出是 UB。因此编译器可以这样推理：“如果程序行为有定义，那么 x + 1 一定没有溢出。既然没有溢出，x + 1 > x 必然为真。”所以整个函数可以直接优化成：

bool f(int x) {
    return true;
}

这不是编译器出错，而是符合 C/C++ 语言规则的优化。这说明 UB 提供的不只是省去检查的机会，它还相当于向优化器提供了一组前提条件。比如编译器可以利用“有符号整数不会溢出”“合法的指针解引用不可能是空指针”“程序不存在未同步的数据竞争”等前提，进行循环变换、消除分支、推断取值范围或重新安排内存访问。如果将所有这些行为都规定为必须检测并抛异常，那么编译器就必须保持相应的异常语义，能做的优化会受到限制。

但这并不意味着 C/C++ 的选择一定优于 Java/Python。Java、Python 的设计目标不同。它们提供了更受约束的内存访问模型，并接受相应的运行时成本。Python 的普通整数甚至支持任意精度，不必遵循固定宽度整数的溢出规则。

C 则诞生于需要直接操作内存和硬件的环境。操作系统内核、驱动程序、嵌入式程序等场景，可能没有异常系统、垃圾回收器或完整的运行时环境。C++ 又继承了与 C 互操作、尽量不为不使用的功能付费等设计取向。