📦 misra-automotive-c — MISRA C:2012 代码审查

技能文档

快速参考

何时激活

在以下情况下激活此技能：

• 用户粘贴 C 代码并请求 MISRA 审查、合规检查或审计
• 使用触发词："misra"、"misra check"、"misra review"、"automotive c"、"embedded c review"、"iso 26262"、"asil"
• 询问"这是否符合 MISRA？"或"这违反了哪些规则？"

审查工作流程 — 按顺序遵循这些步骤

步骤 1 — 解析代码

• 仔细阅读提交的 C 代码的每一行。
• 识别上下文：函数体、头文件、ISR、宏定义、类型声明。
• 记录所有变量类型、控制流路径、预处理器指令。

步骤 2 — 首先检查强制规则（加载 misra-mandatory.md）

强制规则零容忍 — 立即标记每个违规。 优先强制检查：

• 规则 1.3 — 无未定义行为
• 规则 2.1 — 无不可达代码
• 规则 13.2 — 无顺序未确定表达式中的副作用
• 规则 14.3 — 控制表达式不应是不变的
• 规则 15.1 — 无 goto
• 规则 17.1 — 无 特性
• 规则 17.3 — 无隐式函数声明
• 规则 17.4 — 非 void 函数的所有出口路径应有显式 return
• 规则 21.3 — 无 malloc、calloc、realloc、free

步骤 3 — 检查必需规则（加载 misra-required.md、types-and-casting.md、control-flow.md、preprocessor.md）

必需规则必须合规，除非存在正式偏差。检查：

• 固定宽度类型的 typedef 使用（规则 4.6 → D.4.6）
• 基本类型模型违规（规则 10.1–10.8）
• 所有 switch 语句有 default 子句（规则 16.4）
• 所有 if-else if 链以 else 结束（规则 15.7）
• 首选单入口单出口（规则 15.5）
• 所有 struct/union 成员已初始化（规则 9.1）
• 所有宏已加括号（规则 20.7）
• 除非不可避免，否则无函数式宏（规则 20.10）

步骤 4 — 检查嵌入式/内存规则（加载 memory-embedded.md）

• 所有硬件映射寄存器和共享 ISR 变量使用 volatile
• 安全关键路径中任何地方无动态内存分配（堆）
• 无递归（规则 17.2）
• 硬件寄存器和协议字段专用固定宽度整数类型
• ISR 函数：无重计算、无阻塞调用

步骤 5 — 映射到 ISO 26262 ASIL（加载 iso26262-mapping.md）

• 对于每个发现的规则违规，报告其 ASIL 分类
• ASIL D 违规是最高严重性 — 突出显示
• 报告 ASIL A 违规但标记为较低优先级

步骤 6 — 生成违规报告

对于每个发现的违规，按精确格式输出报告：

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
VIOLATION #
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Rule : MISRA C:2012 Rule 
Category : Mandatory | Required | Advisory
ASIL : A | B | C | D | Not mapped
Severity : CRITICAL | HIGH | MEDIUM | LOW
Location : Line  — 
Non-Compliant Code:
Why it violates Rule :
<1–3 sentence plain-English explanation of the rule and why this code breaks it>
MISRA-Compliant Replacement:
Explanation of fix:
<1–2 sentences explaining what changed and why it is now compliant>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

在所有单独违规之后，输出摘要表：

REVIEW SUMMARY
──────────────────────────────────────────────────
Total violations : 
Mandatory :  ← must fix before any safety certification
Required :  ← must fix or raise formal deviation
Advisory :  ← recommended to fix
ASIL breakdown:
ASIL D :  ← safety critical, fix immediately
ASIL C : 
ASIL B : 
ASIL A : 
Not mapped : 
Overall compliance status: FAIL | CONDITIONAL | PASS
──────────────────────────────────────────────────

代码生成工作流程

当请求生成新的汽车/嵌入式 C 代码（不是审查现有代码）时： 无例外地始终应用这些规则：

类型：

• 使用 uint8_t、uint16_t、uint32_t、uint64_t、int8_t、int16_t、int32_t、int64_t — 绝不使用 int、unsigned int、long、char 作为数值数据
• 使用 bool（来自 ）作为布尔值 — 绝不使用整数标志
• 类型转换时始终显式转换 — 无隐式缩窄

内存：

• 绝不使用 malloc、calloc、realloc 或 free
• 所有变量在声明点初始化
• 数组是固定大小、静态分配的
• 硬件寄存器指针声明为 volatile

控制流：

• 无 goto
• 所有 if / else if 链以 else 结束
• 所有 switch 语句有 default
• 所有循环有定义的最大迭代次数
• 每个非 void 函数在可能时在末尾有一个显式 return

函数：

• 所有参数和返回类型使用固定宽度 typedef
• 所有返回值由调用者检查
• 无递归
• 除非有充分理由，否则最多一层指针间接寻址

宏：

• 函数式宏：所有参数和整个表达式加括号
• 优先使用 static inline 函数而非函数式宏
• 每个头文件有 include 守卫（#ifndef FILENAME_H / #define FILENAME_H / ... / #endif）

升级规则

• 如果代码在任何从安全函数可达的路径中包含规则 21.3 违规（动态分配），在报告顶部任何违规之前输出 ⚠️ SAFETY CRITICAL 横幅。
• 如果发现规则 15.1（goto），无论上下文如何都将其标记为 ASIL D。
• 如果在任何函数中发现规则 17.2（递归），如果可见，追踪完整调用链并报告。
• 如果代码看起来是 ISR（函数名包含 ISR、_IRQ、_Handler、_isr，或具有 __attribute__((interrupt)) 注解），以更高严格度应用 memory-embedded.md ISR 规则。