MISRA C: Four Perspectives
From why MISRA C exists to how compliance is verified — the complete picture for embedded engineers and safety managers.
The Engineering Problem MISRA C Solves
The C language specification — ISO/IEC 9899 — defines hundreds of situations where the behaviour of a C program is left to the implementation (compiler and hardware) to determine, or is simply not defined at all. Signed integer overflow, left-shift of negative values, pointer arithmetic beyond array bounds, and reading uninitialised memory are all undefined in C — the standard permits the compiler to generate completely arbitrary machine code when these occur.
In desktop software, undefined behaviour typically manifests as rare, hard-to-reproduce crashes. In embedded safety-critical software, it can produce different binary output at different compiler optimisation settings — the firmware that passes qualification testing behaves differently from the firmware that ships in production. MISRA C was created to eliminate this class of risk by systematically restricting the constructs that cause it.
- Defined in 1998 by MISRA (Motor Industry Software Reliability Association) for UK automotive software
- Current edition: MISRA C:2012 with 2023 Amendment 1 — 143 rules + 16 directives
- Applied across automotive, medical, industrial, aerospace, and defence embedded C software
Seven Categories of MISRA C Restrictions
MISRA C rules are not arbitrary style preferences — each targets a specific failure mode. The 143 rules in MISRA C:2012 fall into seven broad restriction categories:
- No dynamic memory allocation — Rule 21.3 prohibits malloc/realloc/free. Runtime heap allocation leads to fragmentation in long-running embedded systems. MISRA C requires static pool allocation, eliminating heap fragmentation entirely.
- No recursion — Rule 17.2. Recursion makes stack usage unbounded. Banning it allows static stack depth verification and WCET analysis.
- No undefined behaviour — Multiple rules eliminate signed overflow, out-of-bounds pointers, uninitialised reads, and other UB constructs.
- Explicit type conversions — Rules 10.1–10.8 require explicit casts for all narrowing and widening operations, eliminating silent truncations.
- Bounded loops — All loops must have a statically provable maximum iteration count. Required for WCET analysis in real-time safety functions.
- No unsafe standard library functions — Rules 21.x restrict functions with implementation-defined edge cases (atoi, sprintf, gets).
- Restricted goto — Rule 15.1 limits goto to forward-only jumps within a single function, preserving traceable control flow.
What Changed Between Editions
MISRA C:2004 was the widely adopted edition for over a decade. MISRA C:2012 introduced significant improvements:
- C99 support — MISRA C:2012 covers C99 language features, including designated initialisers, variable-length arrays (restricted), and inline functions. MISRA C:2004 was based on C90 only.
- Mandatory vs Required vs Advisory — MISRA C:2012 introduces three compliance tiers. Mandatory rules permit no deviation. Required rules permit deviation with documented justification. Advisory rules are best-practice guidance.
- More precise rule definitions — Several MISRA C:2004 rules were ambiguous in their application to specific code patterns. MISRA C:2012 rewrites these with unambiguous formal definitions.
- Decidability classification — Rules are classified as decidable (static analysis tool can check mechanically) or undecidable (requires manual review). This guides tool selection and review effort.
- 2023 Amendment — Addresses modern compiler practices and static analysis tool capabilities not present in the original 2012 edition.
Most new safety projects target MISRA C:2012. Legacy codebases may still reference MISRA C:2004 in their safety plans — both editions remain in active use.
Why the Distinction Matters for Safety Cases
MISRA C Compliant is a verifiable claim. Specifically: all mandatory rules are satisfied with no undocumented violations; advisory rule violations have written deviation notices with justification; static analysis tools (PC-lint Plus, LDRA, Polyspace, Helix QAC) have been run and results reviewed; a compliance documentation package exists as formal evidence.
Safety auditors under ISO 26262 and IEC 62304 will ask for static analysis evidence, the deviation log, and the compliance documentation. A compliant claim without this evidence will not survive an audit.
MISRA C Compatible, guideline adherent, or MISRA C friendly are marketing terms with no standardised meaning. They typically indicate partial rule application without formal verification — insufficient for safety-critical applications where the value of MISRA C comes from the completeness of verification.
For embedded GUI selection: LVGL and TouchGFX explicitly do not claim MISRA C compliance. emWin has partial alignment. Sparklet is fully, verifiably MISRA C compliant — Embien provides static analysis evidence and compliance documentation to customers for inclusion in safety cases.
