pith. sign in

arxiv: 2605.23490 · v1 · pith:ZEWCDYFCnew · submitted 2026-05-22 · 💻 cs.SE

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

Marius Molz , Niels Schneider , Sven Lechner , Stefan Kowalewski , Alexandru Kampmann This is my paper

Pith reviewed 2026-05-25 03:24 UTC · model grok-4.3

classification 💻 cs.SE
keywords MISRA C++Rustcoding guidelinessafety-critical systemssafe Rustunsafe Rustguideline mappingISO 26262
0
0 comments X

The pith

Rust's language design automatically enforces 47.75% of the MISRA C++ guidelines that apply to it.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper maps all 179 MISRA C++ 2023 guidelines to Rust by checking each rule's rationale for relevance in the new language. It places the rules into six categories and reports that Rust's built-in rules and checks cover nearly half of the 111 that still make sense without change. This matters for safety-critical work because standards require guideline compliance, and automatic enforcement would reduce manual review effort. The mapping further separates safe Rust from unsafe features and shows that the safe subset alone satisfies 36 of the 69 remaining guidelines. Where rules do not translate directly, the authors suggest Rust-specific versions that keep the original safety intent.

Core claim

By systematically examining the rationale of each of the 179 MISRA C++ 2023 coding guidelines, we classify them into six categories according to their applicability to Rust. We find that 47.75% of the 111 rules applicable as-is are automatically enforced by Rust's language design. Of the 69 guidelines that remain relevant, 36 are automatically satisfied when only the safe subset of Rust is used, though they become necessary again if unsafe features are introduced. We also identify areas requiring new Rust-specific guidelines and propose adaptations that preserve the original intent where direct translation is not possible.

What carries the argument

The six-category classification of each MISRA rule based on analysis of its stated rationale to decide applicability, automatic enforcement, or need for adaptation in Rust.

If this is right

  • Safety-critical projects using Rust can treat language rules as satisfying many MISRA requirements without separate enforcement tools.
  • Restricting code to the safe subset removes the need to apply 36 additional guidelines.
  • Unsafe code blocks require re-application of those 36 guidelines plus any others that depend on unsafe features.
  • New guidelines must be written for Rust constructs that have no close MISRA C++ counterpart.
  • The open mapping can be reused to check compliance in existing Rust codebases.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Standards bodies could use the mapping as a starting point for official Rust guidance under ISO 26262.
  • Teams might choose safe Rust by default to lower the total number of rules they must actively check.
  • The same rationale-based method could be applied to map other guideline sets such as CERT or AUTOSAR to Rust.
  • Empirical checks on large Rust projects could reveal whether the auto-enforced rules actually prevent the defects the MISRA rationales describe.

Load-bearing premise

The rationale written for each MISRA rule is enough to decide whether it applies to Rust and whether Rust enforces it, without needing extra domain reinterpretation or real-world testing of the classification.

What would settle it

Re-examination of the full set of 179 rules by safety engineers who reach a different applicability or enforcement verdict on more than a small fraction of them.

Figures

Figures reproduced from arXiv: 2605.23490 by Alexandru Kampmann, Marius Molz, Niels Schneider, Stefan Kowalewski, Sven Lechner.

Figure 1
Figure 1. Figure 1: Template used for guideline analysis The fields for the identifier and the specifier (if the guideline is a rule or directive) are taken directly from [4]. The categorization of each guideline into 1 out of the total 6 classes is given in the field Analysis Result. Furthermore, the discussion to justify the chosen class is contained in the field named Comment, and the code examples are included in the temp… view at source ↗
Figure 2
Figure 2. Figure 2: Overview of the classification procedure and resulting rule count for each class. Class C6 is a strict subset of C4. (C1). Not applicable - C++ Standard Library Usage Restriction: Guide￾lines whose rationale is exclusively tied to deficiencies or design issues in the C++ standard library. One such example is Guideline 25.5.3 “The pointer returned by the C++ Standard Library functions asctime, ctime, gmtime… view at source ↗
read the original abstract

The Rust programming language is increasingly being considered for safety-critical system development. However, established safety standards such as ISO 26262 require the use of coding guidelines that do not yet exist for Rust. This paper systematically examines each of the 179 MISRA C++ 2023 coding guidelines and classifies them into 6 categories based on their applicability to Rust. Our approach analyzes the rationale behind each MISRA rule to determine whether it remains valid in the Rust programming context. We find that 47.75% of the 111 as-is applicable MISRA rules are automatically enforced by Rust's language design, eliminating the need for explicit guideline enforcement. Furthermore, our analysis explicitly distinguishes between safe and unsafe Rust. We find that 69 guidelines are still relevant and still require either direct application or adaptation for Rust. Importantly, 36 of these rules are automatically satisfied when only using the safe subset of the Rust language. However, they are required again if unsafe Rust features are introduced. We also identify specific areas where new Rust-specific guidelines are needed. Where a guideline does not directly translate, we propose Rust-specific adaptations that preserve its intent. All mapping results and supporting artifacts are publicly available as open-source materials at https://github.com/embedded-software-laboratory/MISRust.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

1 major / 2 minor

Summary. The paper systematically examines each of the 179 MISRA C++ 2023 coding guidelines and classifies them into six categories based on applicability to Rust. The classification is performed by analyzing the stated rationale of each rule to determine whether it remains valid, is automatically enforced by Rust's type system/ownership/borrow checker (distinguishing safe vs. unsafe subsets), requires adaptation, or is irrelevant. Key quantitative results are that 47.75% of the 111 as-is applicable rules are automatically enforced by Rust's language design, 69 guidelines remain relevant and require direct application or adaptation, and 36 of those 69 are automatically satisfied when restricting to safe Rust. The authors also identify areas needing new Rust-specific guidelines and propose adaptations where direct translation fails. All mappings and artifacts are released as open-source material on GitHub.

Significance. If the classifications are robust, the work provides a concrete, actionable bridge between established safety-critical coding standards (required by ISO 26262 and similar) and Rust's memory-safety guarantees. The explicit safe/unsafe distinction and the public release of the full rule-by-rule mapping table are particular strengths that allow practitioners and standards bodies to build directly on the results rather than repeat the analysis. The paper thereby reduces the barrier to adopting Rust in domains that currently mandate MISRA compliance.

major comments (1)
  1. [Methodology] Methodology section: The central percentages (47.75% of 111 rules auto-enforced; 36 of 69 still-relevant rules satisfied by safe Rust) rest on a single-pass manual classification of each rule's rationale into the six categories. No inter-rater reliability statistic, no second-reviewer sample of the 20–30 borderline rules (e.g., those involving undefined behavior, pointer aliasing, or initialization), and no spot-check against concrete Rust code examples are reported. A modest shift in interpretation of even a few rules would move the headline figures by several points; this directly undermines confidence in the quantitative claims.
minor comments (2)
  1. [Abstract] Abstract: The six classification categories are referenced but never enumerated; readers must reach the body to understand the taxonomy used for the reported counts.
  2. [Results] Results: While the GitHub repository is cited, the paper does not indicate whether the released artifacts include the raw rationale excerpts or only the final category assignments, limiting independent verification.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for the constructive feedback emphasizing methodological rigor. We address the single major comment below.

read point-by-point responses

  1. Referee: [Methodology] Methodology section: The central percentages (47.75% of 111 rules auto-enforced; 36 of 69 still-relevant rules satisfied by safe Rust) rest on a single-pass manual classification of each rule's rationale into the six categories. No inter-rater reliability statistic, no second-reviewer sample of the 20–30 borderline rules (e.g., those involving undefined behavior, pointer aliasing, or initialization), and no spot-check against concrete Rust code examples are reported. A modest shift in interpretation of even a few rules would move the headline figures by several points; this directly undermines confidence in the quantitative claims.

    Authors: We agree that the classification was performed via single-pass manual analysis by the authors without inter-rater reliability statistics, a second reviewer for borderline cases, or reported spot-checks against concrete code. This is a valid limitation of the presented work. In the revised manuscript we will expand the Methodology section with (1) a more explicit account of the decision process for ambiguous rules, (2) additional concrete Rust code examples illustrating key classifications, and (3) a dedicated limitations paragraph that acknowledges the absence of formal validation metrics while noting that the complete rule-by-rule mapping is publicly released on GitHub to enable independent verification. These changes will improve transparency without altering the core quantitative results. revision: yes

Circularity Check

0 steps flagged

No circularity: external manual classification against independent standard

full rationale

The paper's central output is a one-pass manual mapping of each MISRA C++ 2023 rule's stated rationale into applicability/enforcement categories for Rust (safe vs. unsafe). This is a direct external classification task with no equations, fitted parameters, predictions derived from subsets of the same data, or self-citation chains. The reported percentages (47.75 % of 111, 36 of 69) are simple arithmetic counts from the classification table; the classification itself does not reduce to its own inputs by definition or by any of the six enumerated circular patterns. The method relies on the independent MISRA document and the public Rust language specification.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The mapping depends on the transferability of MISRA rule rationales to Rust semantics; no numerical parameters are fitted and no new entities are postulated.

axioms (1)
  • domain assumption MISRA C++ rule rationales provide sufficient information to determine applicability to Rust
    The paper states it analyzes the rationale behind each rule to classify applicability.

pith-pipeline@v0.9.0 · 5766 in / 1191 out tokens · 33880 ms · 2026-05-25T03:24:56.877501+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

16 extracted references · 16 canonical work pages

  1. [1]

    Eclipse Foundation: Rust - Software Defined Vehicle | The Eclipse Foundation, https://sdv.eclipse.org/special-interest-groups/rust/

    work page

  2. [2]

    Klabnik, S., Nichols, C., Krycho, C., Community, R.: The rust programming lan- guage, https://doc.rust-lang.org/stable/book/

    work page

  3. [3]

    In: 2024 Annual Computer Security Applications Conference (ACSAC)

    Li, Z., Narayanan, V., Chen, X., Zhang, J., Burtsev, A.: Rust for linux: Un- derstanding the security impact of rust in the linux kernel. In: 2024 Annual Computer Security Applications Conference (ACSAC). pp. 548–562 (2024). https: //doi.org/10.1109/ACSAC63791.2024.00054

    work page doi:10.1109/acsac63791.2024.00054 2024

  4. [4]

    The MISRA Consortium Limited, Norwich, UK (2023)

    MISRA: MISRA C++:2023 Guidelines for the use of C++17 in critical systems. The MISRA Consortium Limited, Norwich, UK (2023)

    work page 2023

  5. [5]

    MISRA: MISRA C:2025 – Addendum 6 (MISRA C:2025 ADD6) (2025), https: //misra.org.uk/app/uploads/2025/03/MISRA-C-2025-ADD6.pdf

    work page 2025

  6. [6]

    In: 2025 IEEE Nordic Circuits and Systems Confer- ence (NorCAS)

    Munch, M., Lindner, M., Eriksson, J., Dzialo, P., Lindgren, P.: Rust for Safety and Security Critical Systems. In: 2025 IEEE Nordic Circuits and Systems Confer- ence (NorCAS). pp. 1–7 (Oct 2025). https://doi.org/10.1109/NorCAS66540.2025. 11231205

    work page doi:10.1109/norcas66540.2025 2025

  7. [7]

    In: 2024 IEEE Space Computing Conference (SCC)

    Müller, R., Nehlich, P., Klinkner, S.: Leveraging the rust programming language for space applications. In: 2024 IEEE Space Computing Conference (SCC). pp. 40–50 (2024). https://doi.org/10.1109/SCC61854.2024.00011 14 M. Molz et al

    work page doi:10.1109/scc61854.2024.00011 2024

  8. [8]

    In: 2019 IEEE International Symposium on Software Reliability Engineering Workshops (ISSREW)

    Pinho, A., Couto, L., Oliveira, J.: Towards rust for critical systems. In: 2019 IEEE International Symposium on Software Reliability Engineering Workshops (ISSREW). pp. 19–24 (2019). https://doi.org/10.1109/ISSREW.2019.00036

    work page doi:10.1109/issrew.2019.00036 2019

  9. [9]

    rust-lang: Introduction - Clippy Documentation, https://doc.rust-lang.org/clippy/

    work page

  10. [10]

    rust-lang: Object Oriented Programming Features - The Rust Programming Lan- guage, https://doc.rust-lang.org/book/ch18-00-oop.html

    work page

  11. [11]

    rust-lang: The rust reference, https://doc.rust-lang.org/reference/

    work page

  12. [12]

    https://github.com/rust-lang/rust/issues/113527

    rust-lang:Tracking IssuefortheRustspecification·Issue#113527·rust-lang/rust. https://github.com/rust-lang/rust/issues/113527

    work page

  13. [13]

    org/book/ch20-01-unsafe-rust.html

    rust-lang: Unsafe Rust - The Rust Programming Language, https://doc.rust-lang. org/book/ch20-01-unsafe-rust.html

    work page

  14. [14]

    In: 2024 Se- curity for Space Systems (3S)

    Seidel, L., Beier, J.: Bringing rust to safety-critical systems in space. In: 2024 Se- curity for Space Systems (3S). pp. 1–8 (2024). https://doi.org/10.23919/3S60530. 2024.10592287

    work page doi:10.23919/3s60530 2024

  15. [15]

    In: 18th ESA Workshop on Avionics, Data, Control and Software Systems (ADCSS2024)

    Sommer, J., Gutierrez Rojo, T., Lund, A., Abdelmaksoud, H.I.E.: Rust for space applications and rtems-the good, the bad and the ecss. In: 18th ESA Workshop on Avionics, Data, Control and Software Systems (ADCSS2024). European Space Agency (ESA) (2024)

    work page 2024

  16. [16]

    Vector Informatik GmbH: Vector and HighTec Bring Functional Safety Applica- tions With Rust and AUTOSAR Classic to the Road, https://www.vector.com/ int/en/news/news/safety-applications-with-rust-and-autosar-classic/

    work page