What Is MISRA C, and When Does Embedded Firmware Actually Need It?

Detailed Explanation

MISRA (the Motor Industry Software Reliability Association) originally published its C coding guidelines in 1998 for the automotive industry, where C's permissiveness around undefined behaviour, implicit conversions, and pointer misuse was producing field defects that were expensive and sometimes dangerous. The rule set has since been adopted well beyond automotive — into medical devices, industrial control, aerospace, and rail — anywhere firmware reliability has safety or high-cost-of-failure consequences. The current edition is MISRA C:2012, periodically updated with amendments as the C standard itself evolves (Amendment 4 added guidance aligned with C11/C18 features).

MISRA C doesn't invent new syntax or restrict the language to a subset that can't express real embedded firmware. It restricts how standard C is used, ruling out patterns that are legal C but are either undefined behaviour in disguise, implementation-defined in a way that silently changes meaning across compilers, or simply error-prone in practice.

Rule Categories

MISRA C:2012 classifies each of its roughly 150–170 rules and directives along two independent axes:

• Mandatory — must always be followed; no deviation is permitted under the MISRA guidelines themselves (a small subset, covering the most serious undefined-behaviour risks).
• Required — must be followed unless a formally documented deviation exists, with a stated justification and compensating control.
• Advisory — recommended, but a project may choose not to enforce a given Advisory rule at all, provided that decision is itself documented in the project's MISRA compliance plan.

A second, cross-cutting classification distinguishes Decidable rules (a static analysis tool can determine compliance with certainty from the source code alone) from Undecidable ones (compliance depends on runtime behaviour or context a tool can only approximate, such as "no unused values" in the general case).

Practical Examples

Rules engineers actually hit day to day include:

• No use of the standard library's dynamic memory functions (malloc, free, and similar) in the core rule set — dynamic allocation introduces non-deterministic timing and runtime-failure modes that are hard to bound in a safety analysis. See FreeRTOS heap management for how this plays out specifically in RTOS-based firmware, where static or pool-based allocation is the common alternative.
• Restricted pointer arithmetic — pointer arithmetic is only permitted within a single array's bounds, ruling out common but unsafe patterns like walking a pointer past the end of one array into adjacent memory by coincidence of layout.
• Mandatory braces on every if, else, for, and while body, even single-statement ones — this eliminates an entire class of bugs where a later edit adds a second statement that silently falls outside the conditional because it wasn't wrapped in braces.
• No implicit conversions that could change a value's sign or lose precision — an int assigned to a narrower uint8_t, or a signed value compared against an unsigned one, must be explicit and deliberate, not a silent compiler-inserted conversion the author didn't intend.
• No reliance on the order of evaluation of function arguments or sub-expressions with side effects — C famously does not guarantee evaluation order, so code like f(x++, x++) has genuinely undefined results, not merely "compiler-dependent but consistent" ones.

Static Analysis Tooling

MISRA compliance is checked with a static analysis tool configured for the specific MISRA C guideline edition, not by manual code review alone — the rule set is too large and the violations often too subtle to catch reliably by eye. Commonly used tools include:

• Polyspace (MathWorks) — deep static analysis with formal proof of absence of certain runtime errors, widely used in automotive and aerospace.
• PC-lint / PC-lint Plus (Gimpel/PRQA) — long-established C/C++ static analyser with a mature MISRA rule pack.
• Coverity (Synopsys) — broader static-analysis platform with MISRA rule checking alongside general defect detection.
• Cppcheck — open-source static analyser; its MISRA addon covers a substantial (though not necessarily complete) subset of the rule set, useful as a low-cost first pass rather than a sole compliance tool for a regulated submission.

Whichever tool is used, the practical output is a violation report per rule, which then feeds the compliance-vs-conformance review process described below.

Design Considerations

• Decide the MISRA guideline edition and deviation policy before writing firmware, not after — retrofitting MISRA compliance onto an existing large codebase generates a huge initial violation backlog; adopting it from project start keeps the ongoing discipline manageable.
• A deviation record is a legitimate outcome, not a failure — MISRA's own guidance expects some Required and Advisory rules to be deviated from with justification; the goal is a documented, reviewed decision, not zero violations at any cost.
• MISRA C is a coding standard, not a substitute for the surrounding functional-safety process — a codebase can be fully MISRA-clean and still fail an ISO 26262 or IEC 62304 safety case if the hazard analysis, requirements traceability, and verification testing around it are missing.
• Confirm early which regulatory framework (if any) actually applies, since that determines whether MISRA C is a contractual requirement, a customer expectation, or simply a quality choice the team is free to scope to its own risk tolerance — see what a functional-safety-adjacent electrical standard like IEC 62368-1 requires for how a different but related class of standard operates in a similar "the standard sets the outcome, your process demonstrates it" way.
• Regulated firmware development: Zeus Design's software development team builds embedded firmware with the coding-standard discipline, static analysis, and documentation practices that regulated and safety-relevant products require.

Common Mistakes

• Treating "MISRA compliant" as a binary pass/fail badge instead of the intended documented compliance-with-deviations process, which leads teams to either falsely claim full compliance or abandon the effort entirely when the first Advisory-rule violation appears.
• Running a MISRA static analysis pass only at the end of development, generating an unmanageable violation backlog instead of catching and resolving (or deviating) violations continuously as code is written.
• Assuming a MISRA-clean codebase is automatically safe, when MISRA C only addresses coding-level defect patterns — it says nothing about whether the firmware's requirements, architecture, or test coverage are adequate for the actual safety case.
• Applying full MISRA rigor (and its process overhead) to a project with no regulatory or safety driver at all, when a lighter static-analysis configuration would deliver most of the practical defect-reduction benefit without the documentation burden a full deviation-record process requires.