MISRA C is a coding standard from MISRA, originally the Motor Industry Software Reliability Association, that defines a safe subset of C for critical systems; its first edition appeared in 1998 for vehicle software. It removes or restricts the parts of the language whose behaviour is undefined or unspecified, and it classifies every guideline as mandatory, required or advisory. Mandatory guidelines admit no exception, required ones only a formal documented deviation, and advisory ones a project may relax; compliance means every violation is fixed or justified, not zero warnings.

MISRA C

Details

Full Name: MISRA C — Guidelines for the use of the C language in critical systems, published by MISRA, originally the Motor Industry Software Reliability Association. First edition 1998, then aimed at vehicle-based software; the title above dates from MISRA C:2004, which was followed by MISRA C:2012, the consolidated MISRA C:2023 and the incremental update MISRA C:2025 (misra.org.uk).
Also known as: the MISRA guidelines, MISRA rules; editions by year, such as MISRA C:2012

Core Concepts:

A Safe Subset of C: MISRA C does not add anything to the language. It removes or restricts the parts whose behaviour is undefined or unspecified, or that experience shows are easy to get wrong. Implementation-defined behaviour is not banned outright; where the program depends on it, it has to be documented. What remains is a C that a reviewer and a static analyser can reason about.
Mandatory, Required, Advisory: Every guideline carries a category. Mandatory guidelines admit no exception. Required ones may be broken only through a formal, documented deviation. Advisory ones are recommendations that a project may relax.
Directives and Rules: Rules are stated precisely enough to be checked against the source code. Directives concern the process and the surrounding documentation and cannot be fully checked from the code alone. A tool report covers the rules — completely only for the decidable ones — and at best parts of the directives.
Deviation Instead of Silence: Breaking a required guideline is allowed, but only with a written deviation that names the guideline, the reason, the scope and the approval. Compliance means "every violation is either fixed or justified", not "zero warnings".
The Essential Type Model: MISRA C reasons about the type a value really has — Boolean, character, signed, unsigned, enum, floating — instead of C’s integer promotions. Implicit conversions between these categories, especially narrowing and mixing signedness, are what the model exists to stop.
Typical Themes: No dynamic memory allocation, no recursion, restricted pointer arithmetic, a default in every switch, braces on every body, every return value checked or explicitly discarded, no unreachable or unused code, a restricted preprocessor and standard library.
Rule Texts Belong to MISRA: The guideline texts are copyrighted and sold by MISRA. Name themes and categories freely; for an individual rule number and its wording, the licensed document and a qualified checker are the references — not a model’s memory.

When to Use:

Embedded C for automotive, rail, medical, aerospace or industrial control, where a functional-safety standard such as iec-61508-sil-levels expects a coding standard
Reviewing or rewriting C so that a static analyser’s MISRA report becomes the review checklist
Deciding a project’s compliance policy: which edition, which advisory guidelines are relaxed, who approves deviations
Driving a model: "make this MISRA C compliant and list every deviation with its reason" asks for the subset and for the paper trail, not only for safer code

Common Misunderstandings:

❌ "MISRA compliance means zero warnings" — it means every violation is fixed or covered by an approved deviation
❌ "MISRA is only for cars" — the name has outgrown its origin; the guidelines are used wherever C runs in critical systems
❌ "A model’s rule numbers can be trusted" — in the 2026-10-09 measurement a model cited a "Rule 34.1" that MISRA C does not have; check numbers against the licensed document or a checker
❌ "MISRA C makes C safe" — it removes known hazards; it does not prove the program correct
✓ "Use the edition the project has committed to, check it with a tool, and write down every deviation"

Criticism:

Applied as a compliance checklist, the rules can cause more faults than they prevent. Les Hatton measured MISRA C:1998 and MISRA C:2004 against the same body of code and found that the ratio of real to false positives "is unacceptably low in both". His conclusion goes further: the most fundamental problem of MISRA C:1998 is still unsolved in the 2004 edition, namely "that its unadulterated use as a compliance document is likely to lead to more faults and not less because of the fault re-injection phenomenon" — every change made only to silence a rule carries a chance of introducing a new defect. Hatton, "Language subsetting in an industrial context: a comparison of MISRA C 1998 and MISRA C 2004" (preprint dated 20 November 2005; published in Information and Software Technology 49(5), 2007). The critique predates MISRA C:2012, so read it as a warning about how rules are applied, not as a verdict on the current edition.

Current Status:

The edition a model has in mind is probably MISRA C:2012. MISRA lists MISRA C:2012 as published on 18 March 2013, MISRA C:2023 as published in April 2023 to consolidate the work since and to extend support to C11 and C18, and MISRA C:2025 as published in March 2025 as an incremental update. MISRA, "MISRA C". Name the edition the project uses; guideline numbers differ between editions.