Electronics Guide

MISRA C Editions

MISRA C has evolved through several editions, each addressing additional language features and incorporating lessons from industry experience:

• MISRA C:1998 established the original 127 guidelines for C90, providing the foundation for safe C programming in embedded systems.
• MISRA C:2004 refined the original guidelines, improving clarity and reorganizing the rules while maintaining comprehensive coverage. This edition remained widely used for over a decade.
• MISRA C:2012 addressed C99 (with a defined subset of C11) while reorganizing guidelines into directives and rules, each classified as mandatory, required, or advisory. Directives express intent that cannot be checked from source code alone, such as the requirement that all code be traceable to documented requirements; rules are precise, source-checkable constraints. The 2012 edition also introduced the concept of decidable versus undecidable rules, acknowledging that some guidelines require human judgment rather than fully automated verification, and distinguished rules whose scope is a single translation unit from those requiring whole-system analysis. It defined an initial set of 143 rules and 16 directives.
• Amendments progressively extended MISRA C:2012. Amendment 1 (2016) added fourteen guidelines focused on security, largely derived from the ISO C secure coding technical report and the CERT C rules. Amendment 2 (2020) added coverage of ISO/IEC 9899:2011 (C11) core functionality, including a mapping of undefined, unspecified, and implementation-defined behavior. Amendment 3 (2022) added guidance for C11 and C18 language features that Rule 1.4 had previously prohibited outright. Amendment 4 (2023) completed that work by covering the C11 multithreading library and atomic operations, adding the Rule 22.11 through Rule 22.20 group. Technical corrigenda corrected defects between releases.
• MISRA C:2023 consolidated the guidelines. It rolled up MISRA C:2012 together with its amendments and technical corrigenda into a single document of roughly 221 guidelines, covering C90, C99, C11, and C18.
• MISRA C:2025, published in March 2025, is the current edition. It reorganizes the consolidated guidance and adds further guidelines, bringing the total to approximately 225 active guidelines across C90, C99, C11, and C18, and it introduces the notion of deleted and disapplied rules whose numbers are not reused. Much existing code remains certified against MISRA C:2012 plus selected amendments, or against MISRA C:2023, so several designations are encountered in practice; static analysis tools generally allow the applicable guideline set to be selected per project, and a compliance claim should name the edition explicitly.

Rule Categories

MISRA C organizes its guidelines into three categories based on compliance requirements:

• Mandatory rules must always be followed without exception. These address critical issues such as undefined behavior that cannot be justified in any safety-critical context.
• Required rules must be followed unless a formal deviation process documents the rationale for non-compliance. Deviations require explicit approval and must demonstrate that the non-compliant code does not compromise safety.
• Advisory rules represent best practices that should generally be followed but may be relaxed based on project-specific considerations without formal deviation procedures.

Categories may be tightened but not loosened. A project may promote an advisory guideline to required, or a required guideline to mandatory, but it may never demote a mandatory guideline. Any change to the default categories must be recorded so that reviewers and assessors know which set of obligations the code was actually held to.

Key MISRA C Concepts

MISRA C addresses several fundamental categories of programming issues:

• Type safety: Rules governing implicit type conversions, sign handling, and arithmetic operations prevent unexpected behavior when values overflow or are implicitly converted between types. The essential type model treats each expression as belonging to a type category, such as signed, unsigned, boolean, character, or enumerated, and forbids conversions that cross categories silently.
• Pointer usage: Strict rules limit pointer arithmetic, prohibit null pointer dereferencing, and require explicit null checks before pointer use.
• Control flow: Requirements for switch statement completeness, loop termination guarantees, and structured programming prevent unreachable code and ensure predictable execution paths.
• Memory management: Guidelines restrict or prohibit dynamic memory allocation, preventing memory leaks and fragmentation that could cause system failures.
• Preprocessor usage: Rules limit macro complexity and prohibit dangerous preprocessor constructs that can introduce subtle defects.
• Standard library restrictions: Facilities whose behavior is difficult to bound are excluded, among them setjmp and longjmp, the signal handling facilities, system, and the string-to-number conversion functions that report errors ambiguously.

Demonstrating Compliance

Claiming that code is "MISRA compliant" means little without evidence. The companion document MISRA Compliance:2020 defines what a compliance claim consists of and standardizes the artifacts that support it:

• Guideline enforcement plan: A record of how each guideline is checked, whether by a named static analysis tool, by review, by test, or by a combination. It makes explicit which guidelines the toolchain cannot verify on its own.
• Guideline re-categorization plan: The documented set of category changes agreed for the project, including any categories imposed on suppliers delivering source code.
• Deviation records: A justification for each accepted violation, describing the construct, the reason no compliant alternative was practical, and the analysis showing that safety is not compromised. Deviations require approval and are auditable evidence.
• Guideline compliance summary: The top-level statement of compliance for the whole project, listing each guideline as compliant, deviated, disapplied, or violated. Adopted third-party and legacy code is identified separately, because it is often held to a different standard than newly written code.

MISRA C++:2008

The original MISRA C++ standard targeted C++03 and established guidelines for using C++ safely in critical systems. It addressed class design, inheritance hierarchies, exception handling, and template usage while maintaining compatibility with MISRA C principles where language features overlapped.

MISRA C++:2023

MISRA C++:2023, published in October 2023, targets ISO/IEC 14882:2017 (C++17) and defines approximately 179 rules and directives. It consolidates and supersedes the earlier MISRA C++:2008 guidelines and incorporates the AUTOSAR C++14 coding guidelines, which had become a widely used reference for automotive C++ before being merged into the MISRA effort; AUTOSAR C++14 is no longer maintained separately. Key updates include:

• Modern language features: Guidelines for auto type deduction, range-based for loops, lambda expressions, and smart pointers enable safe use of contemporary C++ idioms.
• Constexpr programming: Rules governing compile-time computation support safer, more efficient code through constant expression evaluation.
• Move semantics: Guidelines ensure correct implementation of move constructors and move assignment operators, preventing resource management errors.
• Template programming: Enhanced coverage of template metaprogramming, variadic templates, and SFINAE addresses the complexity of modern generic programming.

C++ Specific Concerns

Several C++ features require particular attention in safety-critical contexts:

• Exception handling: While exceptions can simplify error handling, their use in safety-critical systems is controversial due to the difficulty of ensuring stack unwinding completes correctly and within timing constraints. Many safety-critical C++ codebases prohibit exceptions entirely.
• Dynamic polymorphism: Virtual functions introduce indirect calls that complicate timing analysis and may impede certain optimizations. Static polymorphism through templates may be preferred when runtime flexibility is not required.
• RTTI: Runtime type information adds overhead and may introduce unexpected behavior. Safety-critical guidelines typically prohibit dynamic_cast and typeid.
• Standard library: Not all standard library components are suitable for safety-critical use. Container implementations may perform dynamic allocation, and some algorithms have non-deterministic timing characteristics.

CERT C Secure Coding Standard

CERT C provides rules and recommendations organized by topic area:

• Input validation: Requirements for validating all external input prevent buffer overflows, format string vulnerabilities, and injection attacks.
• Integer security: Guidelines for integer operations prevent overflow, truncation, and sign errors that could be exploited for security breaches.
• Memory management: Rules governing allocation, deallocation, and access prevent use-after-free, double-free, and buffer overflow vulnerabilities.
• String handling: Secure string manipulation practices prevent buffer overflows and ensure null termination.
• File I/O: Secure file handling prevents race conditions, path traversal attacks, and unauthorized access.

CERT C++ Secure Coding Standard

CERT C++ extends secure coding guidance to C++ specific features:

• Object-oriented security: Guidelines for class design, inheritance, and encapsulation prevent object lifetime errors and access control violations.
• Container security: Secure use of standard library containers prevents iterator invalidation, out-of-bounds access, and resource exhaustion.
• Concurrency: Thread safety guidelines prevent race conditions, deadlocks, and data corruption in multithreaded programs.

Weakness Taxonomies

Secure coding guidelines are most useful when tied to a shared vocabulary for describing defects. The Common Weakness Enumeration (CWE), maintained by MITRE, catalogs classes of software weakness such as out-of-bounds write, use after free, and integer overflow, and the annually published CWE Top 25 ranks the classes most often seen in real vulnerabilities. Individual CERT rules carry mappings to the CWE entries they mitigate, so a static analysis finding can be traced from a rule identifier to a weakness class and, in turn, to the Common Vulnerabilities and Exposures (CVE) records that class has produced in shipping products. For embedded teams, this traceability supports both engineering triage and the vulnerability disclosure obligations that increasingly accompany connected devices.

Types of Static Analysis

• Pattern-based analysis: Tools identify syntactic patterns known to be problematic, such as missing break statements in switch cases or comparisons of floating-point values for exact equality.
• Data flow analysis: Sophisticated analysis tracks how values propagate through programs, detecting uninitialized variable usage, null pointer dereferences, and resource leaks.
• Abstract interpretation: Mathematical techniques compute conservative approximations of program behavior, proving the absence of certain error categories such as array bounds violations or arithmetic overflow.
• Formal methods: The most rigorous approaches use mathematical proofs to verify program properties, though these typically require significant manual effort to specify correctness conditions.

Commercial Static Analysis Tools

Several commercial tools specialize in safety-critical embedded development:

• Polyspace: Uses abstract interpretation to prove the absence of runtime errors, providing definitive results rather than warnings that require investigation.
• LDRA: Provides comprehensive static and dynamic analysis with strong support for safety standards including DO-178C and ISO 26262.
• Parasoft C/C++test: Combines static analysis, coding standard checking, and unit testing in an integrated environment.
• Helix QAC: Specializes in MISRA compliance checking with detailed diagnostic messages and deviation management.
• Klocwork: Focuses on security vulnerabilities and quality defects with incremental analysis capabilities for large codebases.
• Coverity: Uses advanced static analysis to detect defects across large codebases with low false positive rates.
• Astrée: Applies abstract interpretation to synchronous, statically allocated C, aiming to prove the absence of runtime errors in the class of code typical of avionics and automotive control loops.

Open and freely available tools complement the commercial ones. Cppcheck ships a MISRA add-on, the Clang Static Analyzer and clang-tidy integrate directly into LLVM-based toolchains, and Frama-C provides deductive verification and value analysis for C. These tools are valuable during development and for triage, but qualification evidence, deviation management, and coverage of the full guideline set are usually where the commercial products earn their place in a certified project.

Limits of Static Analysis

Static analysis is powerful but not complete, and treating it as a guarantee is itself a hazard:

• False positives: Conservative analyses report conditions that cannot actually occur. High false positive rates waste engineering effort and, worse, encourage teams to suppress findings reflexively. Suppressions should be justified and reviewed like any other deviation.
• False negatives: Unsound analyses may miss real defects. No tool detects every violation of every guideline, which is why the guideline enforcement plan must identify what is checked by review or test rather than by tooling.
• Undecidable guidelines: Some MISRA rules cannot be decided from source code in general. Tools approximate them, and the residual judgment falls to reviewers.
• Dynamic complements: Compiler sanitizers for undefined behavior, address errors, and threading, together with requirements-based testing and structural coverage analysis, catch defects that static tools cannot. DO-178C, for example, requires modified condition/decision coverage for Level A software. Sanitizers instrument the binary and are development-time tools; the code that ships is normally built without them, so their findings must be resolved rather than shipped behind an instrumentation flag.

Tool Qualification

Safety standards require that tools used in development be appropriate for their purpose. Tool qualification demonstrates that a static analysis tool correctly identifies the defects it claims to detect and does not fail to identify violations of checked rules. DO-330 (the tool qualification supplement to DO-178C) provides guidance for aerospace applications, while ISO 26262 defines Tool Confidence Levels, derived from a tool's impact and the likelihood of detecting its errors, for automotive development.

Input Validation

Every function should validate its inputs before proceeding with processing. Validation should occur at trust boundaries where data crosses from untrusted to trusted domains:

• Range checking: Verify that numeric values fall within expected ranges before use in calculations or as array indices.
• Pointer validation: Check that pointers are non-null before dereferencing. Where possible, validate that pointers reference expected memory regions.
• String validation: Verify that strings are properly null-terminated and within length limits before processing.
• Enumeration validation: Verify that enumeration values are valid members of the enumeration before use in switch statements or lookup tables.

Assertions and Runtime Checks

Assertions document invariants and assumptions, catching violations during development and testing. In safety-critical systems, the handling of assertion failures requires careful consideration:

• Development assertions: Assertions that check for programming errors may be disabled in production code to avoid performance overhead, with the assumption that development testing has exercised all paths.
• Runtime checks: Checks that validate external data or detect hardware failures should remain active in production, triggering appropriate error handling rather than simply aborting execution.
• Fail-safe responses: When checks fail, the system should transition to a safe state rather than continuing with potentially corrupted data.

Error Handling Patterns

Consistent error handling ensures that failures are detected, reported, and handled appropriately:

• Return value checking: Every function call that can fail must have its return value checked. Ignoring return values is a common source of undetected failures.
• Error propagation: Errors should propagate to a level where they can be handled appropriately. Silent absorption of errors makes debugging difficult and may mask serious problems.
• Resource cleanup: Error paths must release resources acquired before the failure occurred, preventing resource leaks that could cause eventual system exhaustion.
• Logging and diagnostics: Error conditions should be logged with sufficient context to support post-incident analysis, while being careful not to log sensitive information.

Buffer Overflow Prevention

Buffer overflows occur when programs write beyond allocated memory boundaries, potentially corrupting adjacent data or enabling code injection attacks:

• Bounds checking: Verify array indices before use, especially when indices derive from external input or calculations.
• Safe string functions: Use bounded string functions that accept destination buffer sizes rather than unbounded functions like strcpy and sprintf. Bounded replacements are not automatically safe: strncpy does not guarantee null termination when the source fills the destination, and snprintf returns the length the output would have had, not the length written, so its return value must be range-checked before it is used as an offset.
• Stack protection: Compiler features like stack canaries detect stack buffer overflows at runtime, though these add overhead and should be evaluated for real-time constraints.

Dynamic Memory Considerations

Many safety-critical coding standards prohibit or severely restrict dynamic memory allocation due to the risks of memory leaks, fragmentation, and allocation failures:

• Static allocation: Allocating all memory at compile time eliminates runtime allocation failures and ensures deterministic memory usage.
• Pool allocation: When dynamic allocation is necessary, memory pools with fixed-size blocks simplify management and prevent fragmentation.
• RAII patterns: In C++, Resource Acquisition Is Initialization ensures that resources are released when objects go out of scope, preventing leaks even in the presence of exceptions.

Pointer Safety

Safe pointer usage requires discipline throughout the codebase:

• Initialization: Pointers should be initialized to null or valid addresses at declaration, never left uninitialized.
• Null checks: Check pointers for null before dereferencing, particularly when pointers originate from function calls or external sources.
• Dangling pointer prevention: Set pointers to null after freeing memory to prevent use-after-free. In C++, prefer smart pointers that manage object lifetimes automatically.
• Restricted arithmetic: Limit pointer arithmetic to within array bounds. Prefer array indexing over pointer arithmetic for clarity.

Undefined Behavior and the Optimizer

In C and C++, undefined behavior is not merely a source of wrong answers at runtime; it licenses the compiler to assume the condition never occurs. A signed overflow check written as a test on the result of the overflowing addition, or a null check placed after the pointer has already been dereferenced, may be deleted outright by an optimizing compiler because the standard permits it to assume the undefined case is unreachable. Code that behaved correctly at one optimization level can therefore fail after a compiler upgrade, with no source change and no warning.

This is the practical argument behind rules that forbid relying on implementation-defined behavior, require checks to be written so they precede the operation they guard, and demand that arithmetic be performed in types wide enough to make overflow impossible. Static analyzers that model undefined behavior catch many of these constructs, and comparing the generated object code across compiler versions is a standard sanity check on high-integrity builds.

Synchronization Primitives

• Mutexes: Protect shared data with appropriate mutex types. In real-time systems, a mutex that offers no priority inheritance or priority ceiling protocol allows a low-priority task holding a lock to block a high-priority task indefinitely, the failure mode that famously stalled the Mars Pathfinder lander in 1997.
• Critical sections: Minimize the duration of critical sections to reduce blocking and meet timing requirements.
• Lock ordering: Establish and document consistent lock acquisition orders to prevent deadlocks.
• Lock-free algorithms: Where appropriate, use lock-free data structures to avoid blocking, though these require careful implementation to ensure correctness.

Interrupt Safety

In embedded systems, interrupt handlers execute asynchronously with main program execution:

• Shared data protection: Data shared between interrupt handlers and main code requires protection through interrupt disabling, atomic operations, or careful design.
• Volatile qualification: Variables modified by interrupt handlers must be declared volatile to prevent compiler optimizations from caching values in registers. Volatile is not a substitute for atomicity: it guarantees that the access occurs, not that it occurs indivisibly. A multi-byte counter shared with an interrupt handler still requires an atomic type, a lock, or a brief interrupt mask, and volatile provides no ordering guarantees against non-volatile accesses on weakly ordered processors.
• Minimal handler duration: Interrupt handlers should complete quickly to maintain system responsiveness. Defer extended processing to main-loop or task context.

Review Practices

• Structured reviews: Formal inspection processes with defined roles, checklists, and documented findings provide rigorous verification suitable for high-integrity systems.
• Checklist-driven review: Reviewers use checklists based on coding standards and common error patterns to ensure consistent coverage.
• Author preparation: Code authors should review their own code before submission, using static analysis and self-review to address obvious issues before consuming reviewer time.
• Defect tracking: All review findings should be tracked to closure, with trends analyzed to identify systemic issues requiring process improvement.

Documentation Requirements

Safety-critical systems require extensive documentation that traces requirements through implementation and verification:

• Code comments: Comments should explain intent, assumptions, and non-obvious design decisions. Avoid comments that merely restate what the code does.
• Interface documentation: Function interfaces should document preconditions, postconditions, parameter constraints, and error conditions.
• Deviation documentation: When coding standard rules are violated with justification, deviations must be formally documented and approved.

Tool Integration

Static analysis should be integrated into the development workflow:

• IDE integration: Immediate feedback during coding helps developers learn standards and catch violations early.
• Continuous integration: Automated analysis on every commit ensures consistent checking and prevents regression.
• Build gating: Blocking builds that fail static analysis prevents non-compliant code from progressing through the development pipeline.
• Baselining legacy code: Applying a full guideline set to an existing codebase can produce tens of thousands of findings at once. A common approach is to freeze the existing findings as a baseline, require new and modified code to be clean, and retire the baseline incrementally. The baseline must be recorded as adopted code in the compliance summary rather than quietly ignored.

Toolchain Discipline

Coding standards constrain the source; the toolchain determines what that source becomes:

• Compiler version pinning: The exact compiler, version, and option set form part of the certified configuration. Upgrading a compiler is a change that requires re-verification, because optimization behavior around undefined and implementation-defined constructs can change between releases.
• Option control: Warning levels, language dialect, and optimization flags are project decisions, not developer preferences. Warnings should be treated as errors, and any option that relaxes standard conformance should be justified in the same way as a guideline deviation.
• Reproducible builds: A build that cannot be reproduced bit for bit from archived sources and tools undermines the traceability that certification depends on. Build environments are therefore version controlled and archived alongside the code.
• Third-party and generated code: Vendor drivers, real-time operating system sources, and model-based code generators introduce code the team did not write. Each requires an explicit compliance position, whether qualification of the generator, adoption under documented deviations, or independent verification.

Training and Culture

• Developer training: Engineers need training on coding standards, common vulnerabilities, and the rationale behind rules. Understanding why rules exist promotes genuine adoption rather than mechanical compliance.
• Mentoring: Experienced developers guide newer team members in applying standards correctly and understanding their intent.
• Continuous improvement: Regularly review defect data, analyze root causes, and update processes based on lessons learned.