MISRust: Mapping MISRA-C++ Coding Guidelines to the Rust Programming Language

Technical Summary: MISRust – Mapping MISRA-C++ Coding Guidelines to Rust

Problem Statement
The Rust programming language is increasingly considered for safety-critical system development due to its ownership system, type safety, and memory management model, which prevent classes of errors such as use-after-free, data races, and buffer overflows. However, established safety standards (e.g., ISO 26262, DO-178C, IEC 62304) mandate the use of specific coding guidelines to limit language feature usage and enforce program structures. While comprehensive guidelines exist for C/C++ (such as MISRA C/C++), no equivalent, dedicated set of guidelines exists for Rust. The MISRA Consortium has only published an addendum to MISRA C:2025 regarding Rust, which lacks a detailed, rule-by-rule technical mapping. This absence of established safety-related coding guidelines remains a significant obstacle to achieving compliance for Rust-based safety-critical systems.

Methodology
The authors present "MISRust," a systematic, manual mapping of all 179 MISRA C++ 2023 coding guidelines to the Rust programming language. The methodology involves analyzing the underlying rationale of each MISRA rule to determine its validity within the Rust context. The analysis distinguishes between "safe" Rust (enforced by the compiler) and "unsafe" Rust (where safety guarantees are relaxed).

The authors define a six-category classification framework (C1–C6) to categorize each guideline:

• C1 (Not Applicable): Guidelines tied exclusively to C++ Standard Library deficiencies (e.g., thread-unsafe global state in specific C++ functions).
• C2 (Not Applicable): Guidelines addressing C++ features that do not exist in Rust (e.g., bit-fields, goto, virtual pointer-to-member functions).
• C3 (Rule can be dropped): Guidelines applicable to Rust but automatically enforced by language design, even in unsafe contexts (e.g., preventing redefinition collisions via strict import rules).
• C4 (Rule still required in Unsafe Rust): Guidelines necessary when using unsafe Rust features (e.g., raw pointers, manual memory management), where the rationale remains valid but is not automatically enforced.
• C5 (Rule requires adaptation): Guidelines addressing C++ features absent in Rust, but whose intent is valuable if expressed in a Rust-specific form.
• C6 (Rule still required in Safe Rust): A subset of C4 containing rules that remain necessary even in fully safe Rust, often addressing conceptual programming mistakes independent of language implementation.

The analysis was conducted using Rust version 1.92.0 (edition 2024) and focused on language constructs and the standard library, explicitly excluding Cross-Language Interoperability (FFI) to avoid bypassing Rust's safety guarantees.

Key Results
The study provides a quantitative and qualitative breakdown of the 179 MISRA C++ rules:

• Not Applicable: 57 rules (31.84%) are classified as C1 or C2, as they rely on C++-specific library issues or non-existent features.
• Automatically Satisfied: Of the 122 rules applicable to Rust, 53 rules (29.61% of the total, or 47.75% of the applicable subset) are automatically satisfied by Rust's design (C3). These include protections against memory safety issues that Rust's borrow checker and ownership model enforce by default.
• Still Relevant: 69 rules (38.55%) remain relevant.
  • Safe Rust: 22 rules (12.29%) are required even in safe Rust (C6).
  • Unsafe Rust: 58 rules (32.40%) are required when using unsafe blocks (C4). Notably, 36 of the rules automatically satisfied in safe Rust become violations when unsafe features are introduced.
  • Adaptation Required: 11 rules (6.15%) fall into category C5, requiring specific adaptations to preserve the original intent in a Rust context.

The analysis reveals that object-oriented design topics (Classes, Derived Classes, Special Member Functions) have low relevance in Rust due to fundamental differences in inheritance and polymorphism (Rust uses traits and structs rather than class-based inheritance). Conversely, foundational topics like "Basic concepts," "Expressions," and "Standard conversions" retain high relevance, particularly regarding unsafe code.

Proposed Adaptations
For the 11 rules requiring adaptation, the authors propose specific Rust-centric translations. Examples include:

• Rule 4.1.1 (Conformance): Adapting the requirement for ISO conformance to a future Rust ISO standard.
• Rule 6.0.3 (Global Namespace): Suggesting the use of prelude modules to manage global namespace clutter.
• Rule 12.3.1 (Unions): Recommending Rust enum types as a type-safe alternative to C++ union keywords.
• Rule 15.0.1 (Special Member Functions): Mapping C++ special functions to Rust's Copy, Clone, Drop, and Pin traits.
• Rule 18.5.1 (Exceptions): Adapting the prohibition of exception propagation to require explicit handling of Result types or restricting the use of panic!.

Significance and Claims
The paper claims to provide the first comprehensive, systematic mapping of the entire MISRA C++ 2023 rule set to Rust. The authors assert that this work addresses a critical gap in safety certification for Rust, offering a foundation for future Rust-specific safety standards.

Key implications highlighted include:

1. Reduced Guideline Burden: Approximately 61.45% of the original MISRA rules are either inapplicable or automatically satisfied by Rust, suggesting that a future Rust-specific standard could be significantly more compact.
2. Focus on Unsafe Code: The analysis underscores that while safe Rust reduces the need for many guidelines, the use of unsafe blocks reintroduces risks similar to C/C++. Therefore, future certification frameworks must focus heavily on governing unsafe code sections.
3. Tooling Gaps: The paper notes a deficit in mature tools for validating these guidelines in Rust. While tools like Clippy exist, new static analysis tools or linting rules may be required to achieve parity with MISRA-C++ certification levels.
4. Incremental Adoption: The authors suggest that, given the current lack of tooling and standardization, Rust is more likely to complement rather than replace C/C++ in safety-critical systems in the near term, with gradual integration being the most feasible strategy.

All mapping results and supporting artifacts are publicly available as open-source materials. The authors acknowledge limitations, including the subjective nature of manual classification, the evolving nature of both C++ and Rust, and the lack of independent external verification by a larger group of analysts.