📚 课程目录第4章语言基础规则

第4章：语言基础规则——隐式int、空宏参数与空语句

这一章我们聊聊三个看似基础、但坑特别多的规则。说实话，我见过不少老工程师在这些细节上翻车。尤其是从C89时代过来的项目，隐式int的遗留问题简直防不胜防。

4.1 禁止使用C99之前的隐式int

先问个问题：你写过这样的代码吗？

static count;  // 没写类型，默认int
extern foo();  // 没写返回类型，默认int

嗯，在C89标准里，这是合法的。编译器会默认把没写类型的变量或函数当作int处理。但C99之后，这个特性被删除了。MISRA-C明确要求：所有声明都必须显式指定类型。

核心要求：禁止依赖隐式int，所有变量、函数参数、返回值都必须显式写出类型。

我在项目中遇到过这样一个案例：一个老模块里有个函数声明写成 extern foo();，结果在C99编译器下直接报错。排查了半天才发现是隐式int的问题。你想想看，这种错误在代码审查时很难发现，因为人眼会自动忽略“缺失的类型”。

写法	C89	C99+	MISRA-C
`static count;`	合法，隐式int	非法	禁止
`extern foo();`	合法，返回int	非法	禁止
`const *ptr;`	合法，指向int	非法	禁止
`static int count;`	合法	合法	推荐
`extern int foo(void);`	合法	合法	推荐

我的习惯：写任何声明时，先写类型再写名字。哪怕是个简单的循环变量，我也写成 int i 而不是 i。这能避免很多移植性问题。

4.2 禁止使用空宏参数

空宏参数是什么？看个例子：

#define LOG(msg) printf("[LOG] %s\n", msg)

// 调用时
LOG();           // 空参数，msg为空
LOG("hello");    // 正常调用

在C99之前，空宏参数的行为是未定义的。不同编译器处理方式不同，有的当成空字符串，有的直接报错。MISRA-C明确禁止这种写法。

我曾经踩过的坑：有个项目用了大量日志宏，某个模块的调用写成了 LOG()，在GCC下编译通过，但换到IAR后直接崩溃。原因是空参数被展开成了空语句，导致后续代码逻辑错乱。

正确的做法是：

#define LOG(msg) do { \
    if ((msg) != NULL) { \
        printf("[LOG] %s\n", (msg)); \
    } \
} while(0)

// 调用时
LOG("hello");    // 正常
LOG(NULL);       // 显式传NULL，而不是空参数

说白了，宏参数要么不传，要么传明确的值。不要留空。这不仅是MISRA的要求，也是代码可读性的基本保障。

4.3 禁止使用空语句（除非有注释说明）

空语句就是只有一个分号 ; 的语句。比如：

while (*p++ != '\0')
    ;  // 空语句，等待字符串结束

if (condition)
    ;  // 空语句，什么都不做

MISRA-C要求：空语句必须用注释说明意图。否则，代码审查时没人知道你是故意留空还是忘了写逻辑。

规则要点：

允许空语句，但必须紧跟注释解释原因
注释要写清楚“为什么这里需要空语句”
推荐用 do { } while(0) 替代空语句

我个人的做法是：

// 方式1：带注释的空语句
while (*p++ != '\0')
    ;  /* 等待指针移动到字符串末尾 */

// 方式2：用空块替代
while (*p++ != '\0') {
    // 空循环体，等待指针移动到字符串末尾
}

// 方式3：用do-while(0)包装
#define WAIT_UNTIL_NULL(p) do { } while(0)
while (*p++ != '\0')
    WAIT_UNTIL_NULL(p);

你想想看，如果代码里出现一个孤零零的分号，没有注释，别人怎么知道你是故意还是手误？我曾经在代码审查时看到过这样的代码：

if (error_flag);
    handle_error();

嗯，这里的分号导致 handle_error() 无条件执行。这种bug在静态分析中很容易被检出，但如果没有工具辅助，人工审查很容易漏掉。

知识结构图

下面这张图梳理了本章三个规则的关系和检查要点：

静态分析实战

这些规则在静态分析工具中都有对应的检查项。以PC-lint为例：

隐式int：对应警告 #1924，提示“缺少类型说明符”
空宏参数：对应警告 #10，提示“宏参数为空”
空语句：对应警告 #530，提示“空语句”

我的建议：在项目配置中把这些警告全部设为error级别。别让它们只是warning，否则团队里总有人会忽略。我曾经在一个项目里把隐式int的警告降级为info，结果上线前才发现有3处隐式int导致的bug。

避坑指南

最后总结几个实战要点：

写声明时养成好习惯：先写类型，再写名字。哪怕是个 void 也要写出来。
宏定义时考虑空参数：用 do { } while(0) 包装宏体，避免空参数展开问题。
空语句必须加注释：如果确实需要空循环体，用 { } 并加注释，比孤零零的分号更安全。
静态分析工具要配置严格：把这些规则设为error，从源头杜绝问题。

嗯，这一章的内容就到这里。记住：显式优于隐式，注释说明意图。这是MISRA-C的核心理念，也是高质量嵌入式代码的基础。