MISRA C is a set of coding guidelines for the C language published by the Motor Industry Software Reliability Association (MISRA), designed to improve the safety and reliability of embedded software by restricting or banning C constructs that are undefined, implementation-defined, or historically prone to defects. Security is addressed more directly in later amendments and companion documents.
In practice
MISRA C is most prevalent in safety-critical industries: automotive (ISO 26262), aerospace (DO-178C), medical devices (IEC 62304), and industrial control (IEC 61508). Compliance is often required by supplier contracts or referenced as evidence in a safety case, rather than being a direct certification requirement in itself. The guidelines come in three obligation levels: required rules (must not be violated), advisory rules (strong recommendations), and, in MISRA C:2012, directives that address behaviors outside the code itself, such as how the compiler is configured.
The standard restricts or bans constructs where the C standard itself leaves behavior undefined or implementation-defined, reducing the risk of a well-known class of defects. Common examples include: prohibiting use of dynamic memory allocation (malloc/free) at runtime, restricting implicit type conversions, forbidding certain pointer arithmetic patterns, and requiring all switch statements to have a default clause. Some of the same dark corners of C that cause subtle bugs in general embedded work -- such as the comma operator, integer promotion rules, and unsequenced side effects -- are directly addressed by MISRA rules.
In practice, MISRA compliance is enforced through static analysis tools such as PC-lint, LDRA, Polyspace, Parasoft C/C++test, and Cppcheck (with a MISRA plugin). These tools annotate violations and can integrate into CI pipelines. Teams maintain a "deviation record" for any rule that is intentionally violated; deviations must be documented, reviewed, and approved. A codebase is rarely 100% MISRA-compliant out of the box -- achieving compliance on a legacy project typically requires significant refactoring.
The standard has evolved over several revisions. MISRA C:1998 targeted automotive C90 code. MISRA C:2004 restructured and expanded the rule set. MISRA C:2012 (the current primary edition, updated by 2023 amendments) included C99 support from its original publication, introduced the directive/rule split, and reclassified many required rules as advisory. MISRA C++ is a companion standard covering C++; MISRA has also published separate amendment documents addressing security. Projects starting today should target MISRA C:2012 unless a specific standard mandates an older revision.
Discussed on EmbeddedRelated
Frequently asked
Does MISRA C compliance guarantee my code is bug-free or certifiable?
No. MISRA C compliance reduces a well-understood class of C defects and is evidence of due diligence, but it does not guarantee absence of logical errors,
race conditions, or hardware-interaction bugs. For formal certification (e.g., ISO 26262 ASIL-D or IEC 61508 SIL 3), MISRA compliance is typically one required artifact among many, including hazard analysis, testing evidence, and tool qualification.
Which version of MISRA C should a new project target?
MISRA C:2012 (with the 2023 amendments if available) is the current edition and should be the default choice for new projects. It supports
C99, has a cleaner rule structure, and is what most modern
static analysis tools target. MISRA C:2004 is still referenced in some legacy standards and supplier contracts, but it is no longer updated.
What is a 'deviation' and when is it acceptable?
A deviation is a formal, documented decision to violate a specific MISRA rule in a specific location for a stated technical reason. For example, a hardware abstraction layer may need a cast that violates a pointer-conversion rule, with the reasoning that the target address is known and fixed. Deviations must be reviewed and approved; blanket suppressions without justification defeat the purpose of the standard and are not accepted by auditors.
Does MISRA C prohibit all use of global variables?
MISRA C does not outright ban global variables, but several rules restrict their use -- for example, requiring that objects be declared at the narrowest possible scope, and that external linkage be avoided unless necessary. The concern, discussed in contexts like 'Global Variables vs. Safe Software', is that unrestricted global state makes data flow harder to analyze and increases the risk of unintended side effects.
Can I use MISRA C with C++ or other languages?
MISRA C applies specifically to C. Separate companion standards exist: MISRA C++ (with MISRA C++:2008 as the long-standing edition and a substantially revised 2023 edition now available) covers C++, and MISRA has published guidelines for other languages as well. The two standards are not interchangeable; a C++ project should reference MISRA C++, not MISRA C.
Differentiators vs similar concepts
MISRA C is sometimes conflated with CERT C and the CWE/CWSS vulnerability lists, but they have different origins and emphasis. MISRA C focuses on language-subset safety for critical systems, with mandatory compliance and deviation tracking as part of a broader safety case. CERT C (from Carnegie Mellon's SEI) targets security vulnerabilities and undefined behavior across general C software; its rules are framed around secure coding rather than a certifiable safety subset. In practice, the two standards overlap significantly -- many rules appear in both -- but a project certified against ISO 26262 will reference MISRA C, not CERT C. MISRA C should also not be confused with coding style guides (such as Google C++ Style Guide or Barr-C): style guides address readability and consistency, while MISRA C addresses correctness and safety at the language-semantics level.
