Skip to content

minutes.md

Latest commit

 

History

History
137 lines (119 loc) · 14.5 KB

minutes.md

File metadata and controls

137 lines (119 loc) · 14.5 KB
Raw

Coding Guidelines Subcommittee Meeting on 2026-03-25 @ 1600 CET / 1100 EDT

Link to meeting time in common time zones.

Search Key Description
[todo] Action Item
[decision] Something decided on
[important] Key information

Agenda

  1. Solicitation of notetaker
  2. Acceptance of Previous Meeting Minutes
  3. Introduction of new members
  4. Review batches for CERT C => Rust Mapping (Pete)
  5. Coverage of MISRA C and CERT C in 2026 (Félix / Markus)
    • MISRA C one has a PR up from Markus
    • Félix wanted the review batches done first IIRC
  6. Proposals and ideas for new rules (all)
  7. Progress on ongoing tasks (all)
  8. Round table

Check-in area

  • David Svoboda (:
  • Douglas Deslauriers 🎨
  • Alex Celeste ☕
  • William Barsse
  • Max Jacinto ⚽
  • Arshad Mahmood☔
  • Pete LeVasseur 🎊🦀

Please add your name, and an emoji that describes your day.

Notetaker:

  • William Barsse

For tips on how we take notes in the Safety-Critical Rust Consortium, please see the Meeting Notetaker Role doc.

Housekeeping section

Tasks

  • Open PR for “pro-tips” concerning crate suggestions for use in an Safety Critical context.

Meeting Minutes

  • No objections to the previous meeting’s notes.
  • CertC to Rust mapping, proposal to break into small groups to push discussions along. No objections to the process. 3 (for now) meetings to be organized (see item 4 in Agenda above).
  • Group A
    • PRE32: Agree.
    • DCL31: Agree
    • DCL37: Agree
    • EXP37: Agree
    • EXP44: Agree
    • EXP47: Agree
    • STR34: Agree - although rust has it’s own weirdness - if c is a char, we can do (c as i32) which in theory could result in a negative number because c is represented internally as a u32, but there is no i32::From(c).
    • FIO30: Agree
    • FIO41: Agree
    • ENV30: Mostly Agree
      1. This CERT C rule talks about a selection of specific C library functions. These functions are technically callable in Rust via a C FFI (unsafe).
      2. I suppose the argument could be made that this rule applies to unsafe rust, since they are likely available on any system Rust is used. But IMO it’s equally valid to say that they are out of scope)
    • ENV32: Do not quite agree,
      1. minor: the rationale should talk about panic handler explicitly since they correspond more closely with exit handler.
      2. medium: The CERT rule also talks about potential clean up actions after the exit handler that could be ignored if the rule is violated.
        In Rust, when a panic handler panics the program is aborted (as the rationale points out), this means subsequent clean up is skipped -> same problem
    • ERR34: Agree
    • INT31: Agree
    • FLP32: Agree
    • ENV33: Agree
    • MSC41: Agree
    • MEM31: Agree (Based on the rationale it sounds like the rule should be reclassified from 'maybe' to 'maps to Rust')
    • DCL30: Agree
    • EXP42: Agree
    • ENV31: Agree
  • Group B
    • DCL36: Agreed, linkage specification mismatches are not relevant here
    • DCL41: Agreed
    • EXP45: Agreed, rationale for preventing use of assignments does not apply
    • EXP46: Agreed
    • FIO38: Agreed, this might only be relevant for FFI and doesn’t warrant a rule
    • FIO40: Agreed
    • SIG30: Agreed, signal handling in Rust is outside of the scope of our document
    • SIG31: Agreed
    • ERR30: Agreed, errno is part of libc and not relevant here
    • ERR32: Agreed
    • CON30: Agreed, any method of creating memory leaks wouldn’t be thread-specific
    • CON39: Agreed, the case for preventing this in unsafe code doesn’t rise to the justification of a Rule
    • INT32: Agreed
    • INT34: Agreed
    • CON33: Agreed, but we think library functions like std::env::set_var are worth mentioning since that is closer to the original purpose of the CERT Rule. We checked through the CERT example functions to see if any of those analogies in Rust applied, but they did not
    • CON41: Agreed
    • ARR37: Started to discuss, but ran out of time while discussing pointer provenance
  • Group C
    • INT35: Rust has both a fixed size and a precision => doesn’t apply to Rust. Agreed.
    • STR37: Doesn’t apply to Rust. Agreed.
    • STR38: Doesn’t apply. Agreed.
    • MEM33: Doesn’t apply. Agreed.
    • FIO47: Doesn’t apply, fmt patterns checked at compile time. Agreed.
    • SIG34: Doesn’t apply to Rust std, will be specific to OS Lib (out of scope). Agreed.
    • SIG35: same as SIG34. Agreed.
    • CON31: Doesn’t apply to safe rust though technically possible. May need a broader rule regarding using unsafe to side-step guarantees provided by safe constructs provided by the language (e.g. Mutex). More discussion needed.
    • MSC33: FFI could be used but std and dedicated Rust libs allow working with time without.
      1. Note: would be interesting to have a list, or a ref to a list of crates useful/usable in a safety-critical context.
    • MSC38: Doesn’t apply - would be caught at compile time. Agreed.
    • MSC39: Doesn’t apply - no manipulation of arguments as a data structure. Variadic macros expand all their arguments and translate to Rust code (and checked by the compiler). Agreed.
    • MSC40: without unsafe this doesn’t apply. Again a broad rule regarding how to use / not use unsafe could cover this. More discussion needed.
    • FLP34: definitely applies, existing clippy lints. Agreed.
    • FLP36: same as FLP34. Agreed.
    • FIO42: maps for ‘static lifetimes, or leaking but baseline Rust handles it automatically on Drop.
    • CON38: to be discussed further
    • MSC32: handled by crate outside std, up to it to ensure the generator is seeded (e.g. with a typestate). To be discussed.
    • 4 unaddressed
  • Appreciation of the “fast” review process: Teams would have liked/needed more time to evaluate and make sure the CERTC rules are well understood.
  • Format to express mapping from “foreign” coding standards to SCRC mapping discussed in outside discussion. Proposal to be presented soon.
  • Suggestion for a “pro-tips” section with for instance suggestions of commonly used, crates (eg. chrono, heapless, zerocopy, etc). [see tasks]
  • Topics for next time?

Material

Any material to read before the meeting should be included here.