第四章 核心规则解读（三）：规则101-150——指针与内存管理的硬仗

各位工程师，欢迎来到指针与内存管理的战场。说实话，MISRA-C 里规则 101 到 150 这一块，是我个人觉得最“值钱”的部分。为什么？因为嵌入式系统里，超过一半的严重缺陷都跟指针乱飞、内存泄漏、野指针访问有关。我在项目中见过太多血淋淋的例子，今天咱们就把这些硬骨头啃下来。

4.1 指针算术：别让指针“跑偏”

规则 101-105 主要针对指针算术。很多 C 语言程序员喜欢用 p++、p + n 这种写法，觉得简洁高效。但在安全关键系统里，这种“简洁”往往是灾难的源头。

规则 101：禁止对指向非数组对象的指针进行算术运算

说白了，就是指针加减只能用在数组上。你想想看，如果 p 指向一个单独的 int 变量，你写 p+1，编译器不会报错，但运行时它指向哪里？天知道。我曾经在一个电机控制项目里，接手前任代码发现大量这种操作，结果一跑就随机死机，查了三天才发现是这里的问题。

规则 105：指针算术结果必须指向同一数组元素或尾后位置

这条规则更严格。即使是对数组操作，结果也不能越界。比如：

int arr[10];
int *p = arr + 10;  // 允许：指向尾后位置
int *q = arr + 11;  // 违规：越界了

嗯，这里要注意，尾后位置只能用于比较，不能解引用。我见过有人拿 arr + 10 直接读数据，结果读到了栈上别的变量，整个系统行为都乱了。

规则编号	核心要求	常见违规场景
101	指针算术仅限数组对象	对局部变量地址做 p++
102	指针减法结果必须可表示	两个不同数组的指针相减
103	指针关系运算限于同一数组	p1 < p2 但指向不同对象
105	算术结果不越界	p = arr + 20 超出数组范围

4.2 空指针检查：你的“安全带”系好了吗？

规则 111-118 全是关于空指针的。我个人习惯是：每次解引用指针前，必须检查它是不是 NULL。这不是可选项，是强制项。

规则 111：解引用前必须进行空指针检查

这条看起来简单，但执行起来有讲究。比如：

void process_data(int *p) {
    if (p != NULL) {
        *p = 42;  // 安全
    }
}

但如果你在函数里多次使用 p，每次都要检查吗？MISRA 的建议是：在作用域入口统一检查一次，后续不再重复。我见过有人每个 p->field 前面都加 if (p)，代码变得又臭又长，反而容易漏掉真正的检查点。

规则 118：禁止将空指针常量赋值给非指针变量

这条规则防止你把 NULL 当整数用。比如 int x = NULL; 在有些编译器上能通过，但语义完全错了。我在代码审查时看到过这种写法，问作者为什么这么写，他说“想初始化成0”。我说，那你就写 int x = 0; 啊，用 NULL 只会让读代码的人困惑。

4.3 动态内存分配：能不用就不用

规则 121-135 是动态内存分配的限制。MISRA-C 对 malloc/free 的态度非常明确：在安全关键系统中，禁止使用动态内存分配。

为什么会这样？原因有三：

• 不可预测性：malloc 可能失败（返回 NULL），你处理了吗？
• 碎片化：频繁分配释放会导致堆碎片，最终分配失败。
• 泄漏风险：忘记 free 是嵌入式系统最常见的缺陷之一。

规则 121：禁止使用 malloc、calloc、realloc 和 free

这条规则很绝对。但实际项目中，有时候确实需要动态分配怎么办？我建议的做法是：使用固定大小的内存池。比如：

#define POOL_SIZE 10
typedef struct {
    uint8_t data[64];
    bool in_use;
} memory_block_t;

static memory_block_t memory_pool[POOL_SIZE];

memory_block_t* pool_alloc(void) {
    for (int i = 0; i < POOL_SIZE; i++) {
        if (!memory_pool[i].in_use) {
            memory_pool[i].in_use = true;
            return &memory_pool[i];
        }
    }
    return NULL;  // 池满
}

void pool_free(memory_block_t *block) {
    block->in_use = false;
}

这种方式的优点是：分配时间固定、不会碎片化、容易审计。我曾经在一个航空电子项目中，用这种内存池替代了所有 malloc 调用，经过静态分析工具检查，零违规通过。

4.4 指针类型转换：别玩“变脸”游戏

规则 141-150 涉及指针类型转换。MISRA-C 对类型转换非常严格，尤其是指针之间的转换。

规则 141：禁止将整数转换为指针

这条规则防止你把一个随便的整数当成地址来用。比如 int *p = (int*)0x1234; 在 MISRA-C 里是违规的。为什么？因为硬件地址映射应该通过 #define 或 const 定义，而不是硬编码。

规则 145：禁止将指向不同对象的指针进行转换

这条规则更严格。比如你不能把 int* 转成 float* 然后解引用。这违反了“严格别名规则”（Strict Aliasing Rule）。编译器可能会优化掉你的转换，导致未定义行为。

我遇到过最经典的案例：一个通信协议栈里，有人把接收缓冲区 uint8_t* 强转成 struct packet_header* 来解析报文。看起来没问题，但编译器优化后，字段读取的顺序全乱了。后来改成用 memcpy 逐字段拷贝，问题解决。

// 违规写法
uint8_t buffer[64];
struct header *hdr = (struct header*)buffer;
uint16_t len = hdr->length;  // 可能未定义行为

// 正确写法
struct header hdr;
memcpy(&hdr, buffer, sizeof(hdr));
uint16_t len = hdr.length;  // 安全

4.5 知识体系总览

下面这张图总结了规则 101-150 的核心脉络，你可以把它当作本章的“作战地图”：

4.6 避坑指南：我踩过的那些坑

最后，分享几个我亲身经历过的“血泪史”：

• 坑一：我曾经在一个项目中，用 realloc 扩展缓冲区，但忘了检查返回值。结果 realloc 失败返回 NULL，原来的指针也被释放了，直接导致内存泄漏和野指针。从那以后，我再也不用 realloc，全部改用固定大小缓冲区。
• 坑二：有一次代码审查，我发现有人写了 if (p = NULL) 而不是 if (p == NULL)。这个笔误导致 p 被赋值为 NULL，然后后面的 if (p) 永远为假，功能完全失效。MISRA-C 规则强制要求 if (NULL == p) 这种写法，就是为了防止这种笔误。
• 坑三：动态内存分配在多线程环境下的问题。两个线程同时调用 malloc，如果没有锁保护，堆管理数据结构会被破坏。我见过一个系统因此随机崩溃，最后把所有 malloc 替换成线程安全的内存池才解决。

嗯，指针和内存管理这块，说难不难，说简单也不简单。关键是要养成好习惯：每次写指针操作，都问自己一句“这个指针可能为 NULL 吗？它指向的内存生命周期对吗？” 久而久之，这些规则就会变成你的肌肉记忆。