MISRA Automotive C — Review Skill

Quick Reference

misra-mandatory.md

misra-required.md

types-and-casting.md

memory-embedded.md

control-flow.md

preprocessor.md

iso26262-mapping.md

When to Activate

Activate this skill when the user:

• Pastes C code and asks for a MISRA review, compliance check, or audit
• Uses trigger words: "misra", "misra check", "misra review", "automotive c", "embedded c review", "iso 26262", "asil"
• Asks "is this MISRA compliant?" or "what rules does this violate?"

Review Workflow — Follow These Steps in Order

Step 1 — Parse the Code

• Read every line of the submitted C code carefully.
• Identify the context: function body, header file, ISR, macro definition, type declaration.
• Note all variable types, control flow paths, preprocessor directives.

Step 2 — Check Mandatory Rules First (load

misra-mandatory.md

)

Mandatory rules have zero tolerance — flag every violation immediately. Priority mandatory checks:

• Rule 1.3 — No undefined behaviour
• Rule 2.1 — No unreachable code
• Rule 13.2 — No side effects in expressions where order is unsequenced
• Rule 14.3 — Controlling expressions shall not be invariant
• Rule 15.1 — No

  goto

• Rule 17.1 — No

  <stdarg.h>

  features
• Rule 17.3 — No implicit function declarations
• Rule 17.4 — All exit paths of a non-void function shall have an explicit return
• Rule 21.3 — No

  malloc

  ,

  calloc

  ,

  realloc

  ,

  free

Step 3 — Check Required Rules (load

misra-required.md

,

types-and-casting.md

,

control-flow.md

,

preprocessor.md

)

Required rules must be complied with unless a formal deviation exists. Check:

• Typedef usage for fixed-width types (Rule 4.6 → D.4.6)
• Essential type model violations (Rules 10.1–10.8)
• All switch statements have a

  default

  clause (Rule 16.4)
• All

  if-else if

  chains end with

  else

  (Rule 15.7)
• Single-entry single-exit preferred (Rule 15.5)
• All struct/union members initialised (Rule 9.1)
• All macros parenthesised (Rule 20.7)
• No function-like macros unless unavoidable (Rule 20.10)

Step 4 — Check Embedded / Memory Rules (load

memory-embedded.md

)

• volatile

  used on all hardware-mapped registers and shared ISR variables
• No dynamic memory allocation (heap) anywhere in safety-critical paths
• No recursion (Rule 17.2)
• Fixed-width integer types used exclusively for hardware registers and protocol fields
• ISR functions: no heavy computation, no blocking calls

Step 5 — Map to ISO 26262 ASIL (load

iso26262-mapping.md

)

• For every rule violation found, report its ASIL classification
• ASIL D violations are highest severity — highlight prominently
• Report ASIL A violations but mark as lower urgency

Step 6 — Generate the Violation Report

Output the report in EXACTLY this format for every violation found:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
VIOLATION #<N>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Rule        : MISRA C:2012 Rule <X.Y>
Category    : Mandatory | Required | Advisory
ASIL        : A | B | C | D | Not mapped
Severity    : CRITICAL | HIGH | MEDIUM | LOW

Location    : Line <N> — <brief description of what the line does>

Non-Compliant Code:
  <exact offending line(s)>

Why it violates Rule <X.Y>:
  <1–3 sentence plain-English explanation of the rule and why this code breaks it>

MISRA-Compliant Replacement:
  <corrected code, complete and ready to use>

Explanation of fix:
  <1–2 sentences explaining what changed and why it is now compliant>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

After all individual violations, output a summary table:

REVIEW SUMMARY
──────────────────────────────────────────────────
Total violations   : <N>
  Mandatory        : <N>  ← must fix before any safety certification
  Required         : <N>  ← must fix or raise formal deviation
  Advisory         : <N>  ← recommended to fix

ASIL breakdown:
  ASIL D           : <N>  ← safety critical, fix immediately
  ASIL C           : <N>
  ASIL B           : <N>
  ASIL A           : <N>
  Not mapped       : <N>

Overall compliance status: FAIL | CONDITIONAL | PASS
──────────────────────────────────────────────────

Code Generation Workflow

When asked to generate new automotive/embedded C code (not review existing code):

Always apply these rules unconditionally — no exceptions:

Types:

• Use

  uint8_t

  ,

  uint16_t

  ,

  uint32_t

  ,

  uint64_t

  ,

  int8_t

  ,

  int16_t

  ,

  int32_t

  ,

  int64_t

  — never

  int

  ,

  unsigned int

  ,

  long

  ,

  char

  for numeric data
• Use

  bool

  (from

  <stdbool.h>

  ) for boolean values — never integer flags
• Always cast explicitly when converting between types — no implicit narrowing

Memory:

• Never use

  malloc

  ,

  calloc

  ,

  realloc

  , or

  free

• All variables initialised at declaration point
• Arrays are fixed-size, statically allocated
• Hardware register pointers declared

  volatile

Control flow:

• No

  goto

• All

  if

  /

  else if

  chains end with

  else

• All

  switch

  statements have a

  default

• All loops have a defined maximum iteration count
• Every non-void function has a single explicit

  return

  at the end when possible

Functions:

• All parameters and return types use fixed-width typedefs
• All return values checked by callers
• No recursion
• Maximum one level of pointer indirection unless justified

Macros:

• Function-like macros: all parameters and the whole expression parenthesised
• Prefer

  static inline

  functions over function-like macros
• Include guards on every header (

  #ifndef FILENAME_H / #define FILENAME_H / ... / #endif

  )

Escalation Rules

• If the code contains Rule 21.3 violations (dynamic allocation) in any path reachable from a safety function, output a ⚠️ SAFETY CRITICAL banner at the top of the report before any violations.
• If Rule 15.1 (goto) is found, flag it as ASIL D regardless of context.
• If Rule 17.2 (recursion) is found in any function, trace the full call chain if visible and report it.
• If the code appears to be an ISR (function name contains

  ISR

  ,

  _IRQ

  ,

  _Handler

  ,

  _isr

  , or has a

  __attribute__((interrupt))

  annotation), apply

  memory-embedded.md

  ISR rules with heightened strictness.