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 reducing the number of rules while maintaining comprehensive coverage. This edition remained widely used for over a decade.

MISRA C:2012 represents the current edition, addressing C99 and C11 language features while reorganizing rules into mandatory, required, and advisory categories. The 2012 edition also introduced the concept of decidable versus undecidable rules, acknowledging that some rules require human judgment rather than automated verification.

Amendment updates extend MISRA C:2012 to address additional language features and security concerns, including Amendment 2 which incorporated security-focused guidelines.

Rule Categories

MISRA C:2012 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.

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.

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.

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

The updated MISRA C++:2023 addresses modern C++ features through C++17, reflecting the significant language evolution since 2008. 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.

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.

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. Standards such as DO-330 provide guidance for tool qualification in aerospace applications, while ISO 26262 defines Tool Confidence Levels 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.

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.

Synchronization Primitives

Mutexes: Protect shared data with appropriate mutex types, considering priority inversion prevention in real-time systems.

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.

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.

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.