第11章 静态测试：PC-Lint与Cppcheck、静态分析规则、常见误报处理

静态测试，说白了就是让工具帮你读代码。

不用编译，不用运行，工具就能告诉你哪里可能藏着bug。我刚开始做嵌入式时，觉得这玩意儿可有可无——代码能跑不就行了？直到有一次，一个数组越界的bug在产线上复现了三天才抓到。嗯，从那以后，我再也不敢跳过静态分析了。

11.1 静态分析到底在查什么？

静态分析工具会扫描你的源码，然后对照一套规则去检查。常见的检查项包括：

• 未初始化变量——你声明了却没赋值，直接拿来用
• 数组越界——访问了索引范围之外的元素
• 空指针解引用——指针是NULL，你还去读写它
• 内存泄漏——malloc了没free
• 类型不匹配——比如把int*当void*传，然后解引用
• 死代码——永远不会被执行到的分支

我个人习惯把静态分析当成代码审查的第一关。提交代码前，先跑一遍工具，把明显的问题干掉，再让人去review。这样效率高很多。

11.2 PC-Lint与Cppcheck：两个主流工具

嵌入式圈子里，PC-Lint和Cppcheck是两大主流。我两个都用过，说说我的感受。

11.2.1 PC-Lint

PC-Lint是老牌工具，历史比很多程序员都长。它检查得非常细，细到有时候让你抓狂。举个例子：

int foo(void) {
    int x;
    return x;  // PC-Lint会报：变量x未初始化
}

这种代码在PC-Lint眼里就是红线。我个人觉得，这种严格是好事——你想想看，未初始化的变量在Release模式下可能是个随机值，跑起来就是一颗定时炸弹。

PC-Lint的配置比较繁琐。你需要写一个选项文件，告诉它你的编译器是什么、用了哪些库、遵循什么标准。我第一次配置时花了整整一天。但配好之后，后面就省心了。

11.2.2 Cppcheck

Cppcheck是开源的，轻量级，上手快。它不像PC-Lint那么啰嗦，但该查的都能查到。我建议初学者先从Cppcheck入手。

// Cppcheck能查出这种问题
void bar(int *p) {
    if (p == NULL) {
        *p = 10;  // 空指针解引用
    }
}

你看，逻辑上if里判断了p为NULL，然后紧接着就去解引用——这明显是写反了。Cppcheck会直接报错。

特性	PC-Lint	Cppcheck
许可证	商业	开源（GPL）
检查深度	极深，可自定义规则	中等，覆盖常见问题
配置难度	高	低
误报率	较高（可调）	较低
适用场景	大型项目、安全关键系统	中小项目、快速检查

11.3 静态分析规则：你该关注哪些？

工具自带的规则可能有上千条。你不可能全开，也没必要。我一般会按优先级分三层：

1. 致命错误类：空指针、数组越界、内存泄漏——这些必须开，一条都不能放过。
2. 逻辑可疑类：未初始化变量、类型转换风险、死代码——建议开，但允许有例外。
3. 风格规范类：缩进、命名、注释——看团队要求，我个人觉得可以开，但别太较真。

为什么会这样分？因为致命错误一旦漏掉，线上就是事故。风格问题顶多被同事吐槽两句。

11.4 常见误报处理：别被工具牵着走

静态分析工具不是万能的。它有时候会报一些让你哭笑不得的警告——这就是误报。

举个例子：

void process(int *buf, int len) {
    for (int i = 0; i < len; i++) {
        buf[i] = 0;  // PC-Lint可能报：数组访问可能越界
    }
}

工具不知道len是不是合法值。如果调用方保证len不超过buf的大小，那这就是误报。

我曾经在一个项目中，PC-Lint报了3000多条警告。逐条看完后，发现其中2000多条是误报。剩下的1000条里，有800条是风格问题，真正需要改的只有200条。

处理误报，我建议这样做：

• 先确认：仔细看代码，确认工具是不是真的误判了。
• 加注释抑制：在代码里加注释，告诉工具“这行我确认过了，别报”。比如PC-Lint用//lint -e{xxx}，Cppcheck用// cppcheck-suppress xxx。
• 调整规则：如果某个规则频繁误报，可以考虑降低它的优先级，或者直接关掉。
• 记录在案：把误报和抑制原因写在文档里。不然三个月后你自己都忘了为什么加那条注释。

11.5 知识体系：静态测试的核心逻辑

下面这张图是我自己整理的，把静态测试的流程和关键点串起来了。你一看就明白。

你看，整个流程其实不复杂。源码进去，工具扫描，出来一堆警告。你逐个判断：是真bug就改，是误报就抑制。循环往复，代码质量就上去了。

11.6 避坑指南：我踩过的几个坑

最后分享几个我亲身踩过的坑，希望能帮你省点时间。

• 坑一：我曾经在一个项目里，PC-Lint报了一个“表达式永远为真”的警告。我一看，觉得是误报，随手加了抑制注释。结果上线后，那个分支确实永远进不去——因为条件写反了。嗯，后来我养成了习惯：误报也要先看三遍代码再下结论。
• 坑二：Cppcheck对C++的模板支持不太好。如果你用了大量模板，建议用PC-Lint或者Clang-Tidy。我有个同事用Cppcheck检查一个模板库，报了200多条误报，最后发现是工具本身不支持。
• 坑三：别在项目快交付时才跑静态分析。那时候警告堆成山，你根本改不完。我建议把静态分析集成到CI里，每次提交都自动跑。早发现早修复，成本最低。