MISRA C and MISRA C++ Explained: Rules for Safer Embedded Code 

A signed integer overflow that resolves one way under the development compiler and another way under the production compiler can pass every unit test on the bench and still fail in the field. C doesn’t trap operations with undefined behavior the way a managed runtime would. The program keeps running and may fail unexpectedly later, sometimes through corrupted memory that surfaces nowhere near the original defect. For teams shipping embedded code into vehicles, aircraft, infusion pumps, or rail signaling systems, that failure mode is the reason coding guidelines exist.

MISRA C guidelines reduce those failure modes before code ever runs. Embedded C teams in regulated industries often use MISRA C to define development standards and support defensible compliance claims built around guideline classifications. This guide covers how MISRA C and MISRA C++ classify guidelines, how the rule sets have evolved, and what evidence teams need to build a defensible compliance claim.

What Is MISRA C and MISRA C++?

MISRA C defines a subset of the C language intended to remove or reduce common opportunities for mistakes. The name MISRA originally referenced the Motor Industry Software Reliability Association, but MISRA no longer expands it because the guidelines now apply across sectors well beyond automotive. Its formal title is MISRA C, Guidelines for the use of the C language in critical systems, and the consortium calls MISRA C the de facto compliance standard for developing software in C where safety, security, and code quality are important. The MISRA Consortium Limited manages the guidelines today.

The first edition appeared in the late 1990s and targeted C90 for safety-critical embedded applications in the motor industry. MISRA began as a project inside the UK government’s SafeIT research program, and Ford and Rover later combined their in-house rules into a shared C language subset, an automotive approach to functional safety practices that predates International Organization for Standardization (ISO) 26262 by a decade.

MISRA C++ follows the same model for a different language. First published under the formal title MISRA C++, Guidelines for the use of the C++ language in critical systems, it defines a subset of C++ in which constructs with unspecified, undefined, indeterminate, or implementation-defined behavior are prohibited or flagged for cautious use. Automotive Open System Architecture (AUTOSAR) and MISRA jointly confirmed the merged edition, which targets C++17.

Why Do Embedded Systems Need MISRA C?

Teams choose C for embedded work because it gives embedded programs direct memory control while preserving performance and portability. The same properties also permit programming errors and compiler-dependent behavior, where trapped errors produce immediate exceptions or termination, but untrapped errors let the program keep running as it corrupts state.

Static checking lets teams eliminate whole classes of untrapped errors before the code ever executes. The guidelines target four recurring hazards:

• Undefined behavior: Rule 1.2 requires that no reliance be placed on undefined or unspecified behavior, which covers hazards such as divide by zero, out-of-bounds access, and signed overflow.
• Weak typing: Implicit conversions and implementation-defined type sizes are constrained through typedefs that state size and signedness, such as uint32_t and int8_t.
• Uninitialized variables: Stack variables in C start as garbage, so MISRA requires automatic variables to be assigned before use.
• Pointer and memory hazards: Rules restrict memory allocation and pointer conversions, the mechanisms behind buffer overflows and memory corruption.

These restrictions are why functional safety programs often point to language subsets. Teams working across Automotive Safety Integrity Level (ASIL) tiers commonly use MISRA C during software unit design and implementation, and the relationship also runs back to the guidelines’ origin in International Electrotechnical Commission (IEC) 61508-oriented safety work.

How Has MISRA C Evolved Since 1998?

Later editions, amendments, and consolidations separate the current guidelines from the 1998 original. The table below shows the progression across MISRA C editions and the C language versions each one covers.

Edition	Published	C Standard Coverage	Guidelines
MISRA C 1998	April 1998	C90	Original rules-only edition
MISRA C 2004	October 2004	C90	Expanded rules-only edition
MISRA C 2012	April 2013	C90, C99	Rules plus directives
MISRA C 2023	April 2023	C90, C99, C11, C18	Consolidated rules and directives
MISRA C 2025	March 2025	C90, C99, C11, C18	Current rules and directives

MISRA C 1998 Through MISRA C 2012

The first edition grew out of an agreement between Ford and Land Rover that a joint MISRA publication would serve the industry better than separate in-house guidelines. Its rules targeted C90, and its title, Guidelines for the use of the C language in vehicle based software, reflected a purely automotive scope. MISRA C 2004 replaced vehicle based software with critical systems, expanded the rule set, adopted a one-rule-one-issue structure, and removed the option of claiming compliance without tools. MISRA C 2012 then added C99 support, introduced directives for guidelines that can’t be verified from source code alone, and assigned every guideline a mandatory, required, or advisory category.

Later amendments added security guidance, expanded C11 and C18 coverage, made the MISRA Compliance document mandatory, and added concurrency directives covering data races, deadlocks, and dynamic thread creation. Those changes turned MISRA C from a rules checklist into a compliance framework.

MISRA C 2023 and the MISRA C 2025 Update

MISRA C 2023 consolidated recent amendments and corrigenda into a single document, so teams no longer had to maintain a base standard plus separate amendments. It also expanded coverage for multithreading and atomic types. Published in March 2025, MISRA C 2025 builds incrementally on that edition with policy changes and new guidelines, including removing obsolete rules, preparing MISRA C for C23 support, mapping selected guidelines against the Common Weakness Enumeration (CWE), and examining the guidelines’ applicability to Rust.

How Are MISRA C Guidelines Classified?

Every MISRA guideline carries classifications that determine how teams enforce it and whether a project can deviate from it. Those classifications determine enforcement method and deviation policy because compliance is not a simple pass-fail scan.

Rules vs. Directives

A rule is a source code requirement that is complete, objective, and unambiguous, which means a static analysis tool can check compliance from the source code alone. A directive is open to interpretation or relates to the development process, so verification requires review of process documentation or functional requirements rather than code. Rules also carry a decidability attribute that directives don’t have. In MISRA C 2012, after later amendments, some rules are undecidable, including some in the mandatory category.

Mandatory, Required, and Advisory Categories

The three categories set a project’s deviation policy, and mandatory guidelines allow no deviation under any circumstances. Required guidelines must be followed unless exceptional circumstances apply, and any exception needs a formal deviation record. Advisory guidelines should be followed where practical, with documented justification when they aren’t. Teams can also adjust categories through a Guideline Re-categorization Plan (GRP), although required guidelines can be upgraded to mandatory but never relaxed.

What Does MISRA C++ Cover for C++ Development?

MISRA C++ 2023 defines the safe subset for C++17 development and merges two previously separate guideline sets. The AUTOSAR C++14 guidelines were folded into the next MISRA C++, and the 2023 release completed that merger. The merger creates a single reference for safety-related C++ development.

The C++17 target means teams that want to remain on C++14 must formally deviate from the edition’s language-version requirement. The merger also narrowed the scope, because MISRA C++ 2023 focuses strictly on the implementation language while AUTOSAR C++14 also covered toolchains, documentation, and infrastructure.

Coverage spans modern C++17 features including structured bindings, if constexpr, deprecated features, bool conversions, range-based for-loops where temporary objects can produce undefined behavior, and standard library containers. The edition also introduces the decidability classification that MISRA C has carried since 2012.

How Does MISRA C Compliance Work in Practice?

A separate document governs a MISRA compliance claim and has been mandatory since Amendment 2 for MISRA C 2012. Teams can download it for free, and compliance claims apply per project, with processes and acceptance criteria agreed at the outset.

Building a Compliance Matrix and Documenting Deviations

MISRA Compliance 2020 organizes compliance evidence around the Guideline Enforcement Plan (GEP), which records enforcement methods per guideline, and the GRP, which records the category adjustments described above. Deviation records document every authorized violation following the compliance document’s prescribed format. The Guideline Compliance Summary (GCS) declares the compliance level achieved. For recurring deviations, the MISRA C 2012 Permits document pre-approves common use cases so projects don’t repeatedly re-justify the same violation.

The compliance package should remain synchronized as requirements and verification work change. For an assessor-facing claim, the core evidence should stay current:

• GEP: This artifact records enforcement methods for each guideline.
• GRP: This artifact records any category adjustments agreed for the project.
• Deviation records: These records capture authorized violations with rationale and approval.
• GCS: This summary declares the compliance level, including guidelines that were not applied, violations, and deviations.

These artifacts must track changing requirements and verification work throughout the project, and a requirements management platform can help keep that evidence current.

Using Static Analysis Tools to Verify Compliance

MISRA assumes static analysis as the enforcement mechanism, and ISO 26262 programs commonly use static code analysis. Tool coverage is strongest for decidable and statically enforceable rules.

Tool selection doesn’t remove the manual review burden, because guidelines that aren’t statically enforceable and rules that are undecidable require human judgment. Higher tool confidence levels under ISO 26262 may require tool qualification, and qualifying a MISRA checker involves validation of output formats and implementation-defined aspects of the language.

Which Industries Rely on MISRA C Beyond Automotive?

MISRA’s reach beyond automotive shows up in safety standards that require or reference coding standards. DO-178C, the airborne software standard for aerospace, sets coding-standard objectives aligned with MISRA without naming the guidelines directly. Medical device software follows a similar pattern, since IEC 62304 programs define programming procedures and coding standards as part of their acceptance criteria.

Rail makes the requirement more explicit than many other sectors. EN 50128, the European standard for railway control and protection software, recommends a coding standard across Software Safety Integrity Levels and mandates one at higher levels, and MISRA satisfies the standard’s intent to prevent undefined behavior, remove ambiguity, and restrict library usage. In the nuclear sector, IEC 60880, which governs software for nuclear power plant safety systems, requires adherence to coding standards such as MISRA for Category A functions.

How Jama Connect Supports MISRA C Compliance

MISRA analysis happens at the code level, but the compliance claim built on it depends on requirements and test artifacts staying connected to that code. Jama Connect®, a requirements management and traceability platform, integrates with LDRA’s MISRA-focused static analysis tools, a company that contributed to the MISRA coding guidelines, so code-level verification can tie back to the requirements it satisfies.

Live Traceability™ carries that chain inside Jama Connect itself. When an upstream requirement changes, Jama Connect flags downstream test cases for reassessment before a gap becomes a defect, so MISRA evidence stays aligned with broader safety lifecycle evidence.

Closing MISRA C Gaps Before Code Review Begins

Edition changes point to early planning decisions, including selecting an edition, defining enforcement, and setting a deviation policy that stays current. Retrofitting compliance late means code rework and repeated verification instead. If your team is defining MISRA evidence now, Jama Connect can help keep requirements and verification records connected as the code changes, and you can start a free Jama Connect trial to see the workflow firsthand.

Frequently Asked Questions About MISRA C

Is MISRA C compliance legally required?

MISRA C has no standalone legal mandate, and MISRA documents state that compliance leaves legal obligations in place. Contracts or an invoked functional safety standard can make it binding on a program, and the applicable contract, safety plan, and certification basis determine whether it’s optional or required.

Does MISRA C compliance guarantee bug-free software?

No. Compliance produces code that is easier to maintain and more portable, with less exposure to compiler-dependent failures, while teams still need requirements that meet quality benchmarks and verification work to catch defects a language subset can’t, the same records Jama Connect keeps connected to the code as it changes.

Can MISRA C be applied to a legacy codebase?

Yes, but legacy adoption should account for the risk of introducing defects while making old code compliant. For proven existing code, the benefits of compliance may be outweighed by rework risk under MISRA guidance, so a common path is to baseline existing violations and enforce the guidelines only on new and modified code. Teams should also baseline requirements and verification and validation records so future deviations are judged against the current design.

What is the current version of MISRA C?

MISRA C 2025 is the current edition, while MISRA C++ 2023 is current for C++17 projects. Projects already certified or under assessment against an older edition should document why that edition remains appropriate before moving. Tool support, supplier obligations, deviations, and change impact analysis evidence all affect the transition.

This article was authored by Mario Maldari and published on August 7, 2026.