规则 1.1 (强制)：所有代码必须遵守 ISO C 标准——避免编译器扩展的陷阱
各位工程师，咱们今天聊一个看似简单、实则暗藏杀机的规则——规则 1.1。它要求所有代码必须严格遵守 ISO C 标准，说白了就是：别依赖编译器私藏的那些“小灶”。
你可能觉得这有什么好讲的？我写代码向来标准。嗯，我以前也这么想，直到有一次在项目里栽了个大跟头。
编译器扩展是什么？
编译器扩展，就是编译器厂商在标准 C 之外额外提供的“福利”。比如 GCC 的 __attribute__、Keil 的 __irq、IAR 的 __interrupt。这些扩展用起来确实方便，但代价是什么？
- 代码不可移植：换个编译器，代码可能直接编译不过。
- 行为未定义：很多扩展的行为不在标准范围内，换个环境就翻车。
- 静态分析工具抓狂：MISRA 检查器遇到非标准语法，要么报错，要么直接跳过。
核心原则：如果你的代码里出现了 #pragma、__attribute__、asm 等非标准关键字，就要问自己一句——这个功能真的不能用标准 C 实现吗？
我踩过的坑：一个中断声明的教训
我记得刚入行那会儿，接手一个老项目。代码里大量使用了 IAR 的 __interrupt 关键字来声明中断服务函数。当时觉得没什么，直到客户要求把代码移植到 GCC 平台。
结果呢？整个中断模块全部重写。因为 GCC 根本不认 __interrupt，你得用 __attribute__((interrupt))。更麻烦的是，两个扩展对中断现场的保存和恢复策略还不完全一样，调试了整整两周。
从那以后，我给自己定了个规矩：能用标准 C 解决的问题，绝不用扩展。
常见编译器扩展一览
| 扩展类型 | 常见例子 | 风险等级 |
|---|---|---|
| 关键字扩展 | __interrupt, __irq, __attribute__ |
高 |
| 内建函数 | __builtin_expect, __delay_cycles |
中 |
| 语法扩展 | 零长度数组、嵌套函数、case 范围 |
高 |
| 预处理扩展 | #warning, #include_next |
中 |
| 内联汇编 | asm(), __asm__ |
极高 |
特别注意：内联汇编是 MISRA C 明确禁止的（规则 1.2），因为它完全跳过了 C 语言的类型系统和安全检查。如果你非用不可，必须用 #ifdef 隔离，并写详细的注释说明为什么标准 C 做不到。
如何识别和规避编译器扩展？
你可能会问：我怎么知道哪些是扩展，哪些是标准？其实方法很简单。
- 查标准文档：ISO C 标准附录里列出了所有标准语法和库函数。不在列表里的，大概率是扩展。
- 用静态分析工具：PC-lint、Coverity、SonarQube 都能识别非标准语法。我习惯在 CI 流程里加一道 MISRA 检查，编译扩展直接报错。
- 多编译器测试：至少用两个不同的编译器（比如 GCC + ARMCC）编译一遍。如果其中一个报错，那就是扩展。
- 看编译器手册：每个编译器都会明确标注哪些是扩展。我建议你把手册里“Extensions”那一章通读一遍，心里有个底。
实战案例：用标准 C 替代 __attribute__((packed))
很多嵌入式工程师喜欢用 __attribute__((packed)) 来定义结构体，强制取消字节对齐。但这是 GCC 扩展，不是标准 C。
标准 C 怎么做？用 uint8_t 数组 + 手动偏移。虽然代码长了点，但绝对可移植。
/* 非标准写法：依赖 GCC 扩展 */
struct __attribute__((packed)) SensorData {
uint16_t id;
uint32_t value;
uint8_t status;
};
/* 标准 C 写法：手动控制布局 */
#define SENSOR_DATA_ID_OFFSET 0
#define SENSOR_DATA_VALUE_OFFSET 2
#define SENSOR_DATA_STATUS_OFFSET 6
#define SENSOR_DATA_SIZE 7
void sensor_data_pack(uint8_t *buf, uint16_t id, uint32_t value, uint8_t status) {
buf[SENSOR_DATA_ID_OFFSET] = (uint8_t)(id & 0xFF);
buf[SENSOR_DATA_ID_OFFSET + 1] = (uint8_t)((id >> 8) & 0xFF);
buf[SENSOR_DATA_VALUE_OFFSET] = (uint8_t)(value & 0xFF);
buf[SENSOR_DATA_VALUE_OFFSET + 1] = (uint8_t)((value >> 8) & 0xFF);
buf[SENSOR_DATA_VALUE_OFFSET + 2] = (uint8_t)((value >> 16) & 0xFF);
buf[SENSOR_DATA_VALUE_OFFSET + 3] = (uint8_t)((value >> 24) & 0xFF);
buf[SENSOR_DATA_STATUS_OFFSET] = status;
}我的习惯：如果项目必须用扩展（比如访问特殊功能寄存器），我会用 #ifdef 把扩展代码包起来，并提供一个标准 C 的 fallback 实现。这样换编译器时，至少能编译过，再慢慢调。
知识结构图：编译器扩展的陷阱与对策
下面这张图总结了编译器扩展的核心风险和我们应对的策略。你可以把它贴在工位上，写代码时瞄一眼。
避坑指南：我曾经...
我曾经在一个项目里看到有人用 #pragma 来优化循环，结果换了个编译器，#pragma 直接被忽略，性能掉了一半。调试了三天才发现是 #pragma 不兼容。
所以我的建议是：写代码时，先想标准 C 能不能做。如果能，就别碰扩展。如果必须用，一定要加注释、加隔离、加 fallback。
你想想看，一个项目活三五年是常事，中间换编译器、换芯片、换工具链都有可能。今天偷的懒，明天就是债。