Skip to content

minutes.md

Latest commit

 

History

History
136 lines (118 loc) · 8.6 KB

minutes.md

File metadata and controls

136 lines (118 loc) · 8.6 KB
Raw

Coding Guidelines Subcommittee Meeting on 2026-04-15 @ 1600 CEST / 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 met with Markus and will walk us through the "harmonized" version that should work for MISRA, CERT both
  6. Interest in the MISRA C++ mapping
    • Please register interest on this Zulip thread
    • Pete/Alex/Joel are working out how we can have some kind of copy of the MISRA documents (C, C++) held in the jurisdiction of the Rust Foundation in support of members to be able to work on coding guidelines
  7. Overview of Safety-Critical Rust - Rust Project Goals Roadmap (Pete)
  8. Proposals and ideas for new rules (all)
  9. Progress on ongoing tasks (all)
  10. Round table

Check-in area

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

  • Pete LeVasseur ☕☕
  • Oreste Bernardi🏥
  • Samuel Tardieu 🎺
  • Jason Newcomb ❄️
  • Douglas Deslauriers 🌞
  • Arshad Mahmood 🌦️
  • Félix Fischer 🙂
  • William Barsse
  • Max Jacinto 🫠
  • Arthur Hicken 🌄🙂
  • Kaneko Satoshi

Notetaker:

  • Douglas Deslauriers

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

Housekeeping section

Tasks

  • [Pete] Determine a list of people interested in Clippy integration and working with them
  • [Pete] Determine an easy Clippy lint for trial run
  • [Pete] Reach out to Markus about MISRA C mapping
  • [Doug] Open separate issue for PRE31

Meeting Minutes

  • Previous meeting notes
    • No objections
  • Clippy collaboration
    • The safety critical rust consortium members don’t want to have to use another separate tool to verify coding guidelines
    • There are some coding guidelines which are in a good enough space that Clippy lints could start to be implemented
    • Suggestion to have a few interactive sessions to help introduce our team to implementing or starting to implement lints
      1. What to look for when opening an issue
      2. How to best provide suggestions
    • It was suggested to open a new issue/PR against Clippy with the SCRC tag
      1. It is possible to open issues without the intention to implement a lint, a contributor will hopefully be found
    • During collaboration, the SCRC team is proposed as mostly reviewing the implementation of lints to ensure they work with all examples
    • There is are existing tutorial information, which could be a guide to SCRC members
    • Clippy is not looking to do global analysis, and will doing a crate by crate analysis
    • How does Clippy deal with undecidable rules?
      1. If Clippy can determine a violation it shows a message, if it can prove no violation then no message, the question is for when Clippy can’t know
      2. It entirely depends on the lint, some false positives are acceptable, sometimes false negatives are acceptable
    • Are most Clippy lints done on the MIR level?
      1. Clippy has its own const evaluator which is used for some lints
    • Does Clippy denote undecidable lints on their lint page?
      1. It might be good to add this to the database for SCRC use cases
      2. There are two possible ways to look at decidability, one from a theoretical point of view (guidelines), one from a tool point of view (Clippy)
      3. No objection to adding that classification, but that might be a good deal of work to label them
    • Proposed easy to implement lints
      1. The 'as' operator should not be used with numeric operands
      2. Avoid out-or-range shifts
      3. Do not shift an expression by a negative number of bits or by greater than or equal to the bitwidth of the operand
      4. Do not use an integer type as a divisor during integer division
  • MISRA C Mapping
    • The work has already been done by Alex C, etc.
    • Markus has been working on this
  • MISRA C++ Mapping
    • Douglas and Max have expressed interesting performing this mapping
    • The SCRC is looking to purchase some copies for the institution
  • CERT C Mapping
    • Useful feedback has been provided on all of the batches of issues
    • There are still some loose ends to some of the feedback, and the original poster may be tagged ask for clarification
  • Break-out Sessions
    • Group batch 1
      1. PRE31: Agreed, might split this out into a separate advisory guideline
    • Group batch 2
      1. PRE30: Agree; no observations
      2. DCL38: Agree; no observations
      3. EXP35: Agree; no observations
      4. EXP43: Agree; should only be taken into consideration when writing unsafe Rust and having lifetimes be involved
      5. ARR32: Agree; no observations
      6. ARR38: Agree; Would be interesting to have a general position with respect to recreating C-like behavior (e.g. a field that represents the size of a data structure) when an idiomatic Rust solution exists. However FFI does stand out as an area where this is likely to be necessary.
      7. STR32: Should be taken into consideration when writing unsafe Rust, specially with FFI/C-bindings (CStrings)
      8. FIO34: Should be taken into consideration depending on the use-case; no-std projects may need the raw bytes
  • Round Table
    • Macros are hard
    • There is a discussion on batch 4 about FFI, please take a look at the second part of the linked comment if you have thoughts
    • FFI is an important design space to think about guidelines in, and CERT C can teach us about interfacing with C

Material

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