Misra C++:2023

Original Article ↗ Hacker News Discussion ↗

MISRA C++:2023, a paid guideline for using C++17 in safety‑critical embedded systems (especially automotive), prompts debate over its value, scope, and practical impact. Commenters describe it as a stricter, safer subset of C++ that improves on the 2008 version and aligns with AUTOSAR C++14, but critics argue some rules are counterproductive, lag behind the ISO standard, and mainly benefit vendors of compliance tools. Much of the exchange focuses on exception handling, dynamic memory, tool qualification for standards like ISO 26262, and the limited availability of open-source static analyzers that fully support the new rules.

Overview of MISRA C++:2023

  • Guidelines for using C++17 in critical/safety‑relevant systems (especially automotive/embedded).
  • Defines which language features and practices are allowed, restricted, or banned to improve predictability, safety, and reliability.
  • Seen as a major improvement over MISRA C++:2008 and heavily influenced by AUTOSAR C++14.

Relationship to C++ Standards and Other Guidelines

  • Targets C++17 even though newer C++ standards exist; commenters note many toolchains are still catching up, so this is acceptable in safety‑critical contexts.
  • Compared to other coding standards: SEI CERT C is described as “how to use X safely,” while MISRA tends to forbid or tightly constrain dangerous APIs.
  • Some point to royalty‑free alternatives (e.g., Japanese embedded coding guide), but those are mostly C‑focused and less helpful for C++.
  • One view: each such guideline effectively defines a “subset language,” contributing to C/C++ fragmentation.

Tooling, Licensing, and Open Source

  • Standard costs money and is not an open standard; some suggest this discourages FOSS tooling.
  • Static analysis ecosystems are dominated by proprietary tools; few open tools support MISRA well.
  • Mention of open‑source analyzers (e.g., NaiveSystems Analyze, Cppcheck, CodeQL-based rules), but coverage and version support can lag or be split between community and paid editions.

Exceptions, Dynamic Memory, and Error Handling

  • Dynamic memory is prohibited in MISRA C++:2023; exceptions are surprisingly allowed and even recommended for rule compliance.
  • Debate is intense:
    • Pro‑exceptions: essential for sane error propagation in multi‑threaded or large systems; help with RAII and invariants.
    • Anti‑exceptions: problematic for embedded due to code size, performance, determinism, and toolchain constraints; many large C++ projects and embedded systems disable them.
  • Turning off exceptions (-fno-exceptions) can reduce binary size but interacts badly with the standard library, leading to potential UB or reliance on unspecified std::terminate behavior.

Automotive and Safety‑Critical Context

  • MISRA is typically applied to safety‑critical ECUs (engine, brakes, airbags, etc.), not infotainment.
  • Some criticize automotive software quality, but most agree MISRA is not the main problem; process, management, outsourcing, AUTOSAR, and complexity are bigger issues.
  • Tool qualification and ISO 26262 compliance are major constraints; using mainstream compilers in safety‑critical code requires heavy documentation and testing.

C++ vs. “Safe Languages”

  • Some argue that C++’s complexity and undefined behavior make it fundamentally unsuited for safety, suggesting Rust as a “safe C++.”
  • Others propose “MISRA‑for‑Rust” ideas and note that even in safer languages, style guidelines and subsets would still be valuable.