4. 违规代码实战（一）：规则 1.1（未定义行为）的识别与修复

各位工程师，咱们今天聊点实在的。MISRA C 的规则 1.1，全称是“程序不得包含任何未定义行为”。

听起来像句废话对吧？但我在项目里见过太多人栽在这上面。说白了，未定义行为就是 C 标准里那些“编译器想怎么干就怎么干”的灰色地带。你写的时候觉得没问题，换个编译器、换个优化等级，程序就崩了。

4.1 什么是未定义行为？

先给个准确定义：C 标准里明确说了，某些操作的结果是“不可预测的”。编译器可以自由发挥——可以按你预期的跑，可以崩溃，甚至可以悄悄删掉你的代码。

我举个例子你就明白了：

int a = 5;
int b = a++ + ++a;   // 未定义行为

这段代码，不同编译器结果可能完全不同。有的出 12，有的出 13，有的直接报警。你想想看，这种代码放到安全关键系统里，谁敢用？

4.2 常见的未定义行为模式

我整理了一份清单，都是我在实际项目中踩过的坑。你对照着检查自己的代码，大概率能揪出几个。

类别	典型例子	风险等级
有符号整数溢出	int x = INT_MAX + 1;	高
数组越界访问	arr[10] 当数组只有 10 个元素	极高
空指针解引用	*p 当 p == NULL	极高
除零操作	a / 0	高
序列点违规	i = i++;	中
移位操作越界	1 << 32 当 int 是 32 位	中

嗯，这里要注意。很多人觉得“我写嵌入式这么多年，不会犯这种低级错误”。但我在代码评审里，几乎每次都能抓到至少一个未定义行为。尤其是移位和整数溢出，隐蔽性特别强。

4.3 实战案例：有符号整数溢出

咱们看一个真实案例。这是我从一个车载控制器的代码里摘出来的：

int32_t calculate_speed(int32_t delta_time, int32_t delta_distance) {
    // 速度 = 距离 / 时间
    int32_t speed = delta_distance / delta_time;
    return speed;
}

表面上看没问题。但你想过没有——如果 delta_time 是 0 呢？除零，未定义行为。如果 delta_distance 是 INT32_MAX，delta_time 是 1，结果正常。但如果 delta_distance 是 INT32_MAX，delta_time 是 -1 呢？除法本身没问题，但后续逻辑可能溢出。

更隐蔽的是这个：

int32_t result = delta_distance + 100;  // 如果 delta_distance 接近 INT32_MAX

加法溢出，C 标准说这是未定义行为。但在大多数嵌入式编译器上，它默默给你一个负数结果。你的程序继续跑，但数据已经错了。

4.4 实战案例：序列点违规

这个坑我年轻时候踩过。看代码：

int i = 0;
while (i < 10) {
    arr[i] = i++;  // 未定义行为
}

为什么？因为 arr[i] 和 i++ 之间没有序列点。编译器可以先取 i 的值做下标，再自增；也可以先自增，再用新值做下标。两种结果完全不同。

我曾经在一个通信协议栈里看到类似的代码，导致数据包索引错乱。排查了整整两天，最后发现是这种“看起来没问题”的写法。

修复很简单：

int i = 0;
while (i < 10) {
    arr[i] = i;
    i++;  // 分开写，序列点明确
}

4.5 知识结构图：未定义行为识别流程

下面这张图，是我自己总结的识别流程。每次代码评审，我都按这个步骤过一遍。

4.6 工具辅助：静态分析怎么用

光靠人眼审查，效率太低。我建议你配合静态分析工具一起用。

常用的工具有：

• PC-lint：老牌工具，对 MISRA C 支持很好。我习惯在编译前跑一遍，能抓到 80% 的未定义行为。
• Coverity：商业工具，深度分析能力强。适合做 nightly build 的自动化检查。
• Clang Static Analyzer：免费，集成在 LLVM 里。对序列点违规和空指针检查特别敏感。

但注意，工具不是万能的。我记得有一次，PC-lint 没报错，但代码在 ARM 和 x86 上行为完全不同。最后还是靠人工审查发现的——是移位操作依赖了实现定义的行为。

4.7 避坑指南：我曾经犯过的错

最后分享几个我自己的教训，希望能帮你少走弯路。

• 别信“编译器会处理”：我曾经觉得“现代编译器优化好，溢出会 wrap around”。但 C 标准明确说这是未定义行为，编译器有权在溢出时做任何优化。后来升级编译器，代码直接跑飞了。
• 别在表达式里写自增自减：a = b++ + c-- 这种写法，看着很酷，但序列点问题防不胜防。我现在的习惯是：自增自减单独成行。
• 移位操作一定要检查位数：1 << n 当 n 大于等于类型位数时，是未定义行为。我习惯加个断言：assert(n < sizeof(int) * 8);

嗯，今天就先聊到这儿。规则 1.1 看起来简单，但实际项目里陷阱很多。你回去可以翻翻自己的代码，按我给的流程过一遍，大概率能发现几个“定时炸弹”。