92、未定义行为：C 语言中常见的未定义行为

说实话，我写了十几年嵌入式C代码，最怕的不是语法报错，而是那种“编译能过、运行偶尔崩、换个编译器结果还不一样”的bug。这种bug的根源，十有八九是未定义行为。

未定义行为（Undefined Behavior，简称UB），说白了就是C语言标准没规定“这种情况下该怎么做”。编译器可以自由发挥。你觉得它该这么干，它偏那么干。你换个优化等级，结果又变了。

我有个血的教训。早年做一款工业控制器，代码里有个有符号整数溢出。在Keil MDK下跑了两年都没事，换了IAR编译器后，系统偶尔死机。查了整整三天，最后发现是溢出导致优化后的代码跳到了错误分支。嗯，从那以后，我对UB就特别敏感。

什么是未定义行为？

C语言标准（ISO/IEC 9899）明确列出了几十种未定义行为。标准的态度是：“我不负责，你自己看着办。” 一旦触发UB，程序可能：

• 正常运行，啥事没有
• 运行结果错误
• 直接崩溃
• 被编译器优化掉，代码消失
• 产生安全漏洞（缓冲区溢出、格式化字符串攻击等）

你想想看，一个bug能表现出这么多症状，排查起来得多痛苦。

最常见的未定义行为清单

我把工作中踩过的坑整理了一下，下面这些是C语言里最常碰到的UB。我建议你把它打印出来贴工位上。

未定义行为	示例代码	可能后果
有符号整数溢出	int a = INT_MAX + 1;	结果不确定，可能被优化掉
数组越界访问	int arr[5]; arr[5] = 10;	踩内存、崩溃、安全漏洞
解引用空指针	int *p = NULL; *p = 1;	段错误、系统复位
除零操作	int a = 1 / 0;	浮点异常、程序终止
使用未初始化的变量	int x; if(x) {...}	随机行为，不同编译器不同
修改字符串字面量	char *s = "hello"; s[0] = 'H';	只读段写入，崩溃
同一个表达式中多次修改变量	i = i++ + ++i;	结果完全不可预测
移位操作数超过位宽	int a = 1 << 33;（32位int）	结果未定义
违反严格别名规则	通过不同类型的指针访问同一内存	优化后逻辑错误
使用realloc后继续使用原指针	p = realloc(p, 100); free(p);	double free、内存损坏

为什么编译器不警告？

很多初学者会问：“编译器为什么不直接报错？” 原因很简单——检测UB需要额外的运行时开销。嵌入式系统资源有限，不可能每条指令都检查一遍。而且有些UB在编译期根本看不出来，比如数组越界，得运行时才知道。

我个人习惯在开发阶段开启编译器的所有警告：

// GCC 常用选项
-Wall -Wextra -Wpedantic -Werror
-fsanitize=undefined  // 运行时检测UB

加了 -fsanitize=undefined 后，程序会在触发UB时打印详细信息。这个工具救过我很多次。

几个经典案例深度分析

案例1：有符号整数溢出

int overflow_demo(void) {
    int i = 0;
    for (i = 0; i <= 100; i++) {
        // 假设 i 是 int，最大值 2147483647
        // 如果 i 加到 INT_MAX 后再加1，就溢出了
    }
    return i;
}

你可能会想：“溢出后变成负数，循环不就结束了吗？” 不一定。编译器看到 i <= 100 这个条件，如果它推断出 i 不可能溢出（因为标准说溢出是UB），它可能直接把循环优化成死循环，或者干脆把整个循环删掉。我在项目中遇到过类似情况，优化后的代码完全跳过了循环体，导致外设没初始化。

案例2：序列点问题

int a = 1;
a = a++ + ++a;  // 经典UB
printf("%d\n", a);  // 猜猜输出多少？

不同编译器输出不同。有的输出5，有的输出6，有的输出4。为什么？因为C标准规定：在两个序列点之间，一个变量最多只能被修改一次。这里 a 被修改了三次（两次++，一次赋值），属于UB。

我建议你写代码时，一条语句里不要对同一个变量做两次以上的修改。拆成多行写，可读性更好，也安全。

案例3：违反严格别名规则

float f = 3.14f;
int *p = (int *)&f;  // 通过int指针访问float对象
printf("%d\n", *p);   // UB！

这段代码想干什么？想看看float的二进制表示。但C标准说：你不能通过不兼容类型的指针访问对象，除非是通过 char*。编译器看到 int* 和 float* 指向同一块内存，它可能认为这两个指针不会重叠，从而做出错误的优化。

正确的做法是用 memcpy 或者 union：

float f = 3.14f;
int i;
memcpy(&i, &f, sizeof(i));  // 合法
// 或者用 union
union { float f; int i; } u = { .f = 3.14f };
printf("%d\n", u.i);  // 合法

如何避免未定义行为？

我总结了几条实战经验，分享给你：

1. 开启所有编译警告，把警告当错误处理。这是最便宜的防线。
2. 使用静态分析工具。比如 PC-Lint、Cppcheck、Clang Static Analyzer。它们能发现很多编译器发现不了的UB。
3. 运行时检测。GCC的 -fsanitize=undefined 和 -fsanitize=address 是神器。嵌入式环境如果跑不了，可以在单元测试里用。
4. 写代码时多问自己一句：“这个操作C标准有定义吗？” 不确定就去查一下。
5. 避免“聪明”的写法。比如一行里搞三个副作用、用指针强转做类型双关。代码是写给人看的，不是写给编译器炫技的。

知识体系图

下面这张图总结了未定义行为的分类、常见场景和防护手段。你可以把它当作一个快速参考。

写在最后

未定义行为是C语言里最隐蔽的陷阱。它不像语法错误那样直接报错，而是像一颗定时炸弹，不知道什么时候爆炸。我个人觉得，对待UB的态度，很大程度上决定了一个C程序员是“入门级”还是“资深级”。

我曾经在一个项目里，因为一个未初始化的局部变量，导致产品在客户现场偶发死机。查了整整一周，最后用JTAG单步跟踪才发现那个变量在优化后被分配到了某个特殊寄存器，初始值正好是0xDEADBEEF。嗯，从那以后，我所有局部变量都初始化，哪怕下一秒就赋值。

记住一句话：不要和编译器玩猜谜游戏。你写的是C代码，不是C++模板元编程。清晰、简单、可预测，才是嵌入式C的王道。