|
| 1 | +# **Coding Guidelines Subcommittee Meeting on 2025-07-30 @ 0800 BST / 0900 CEST / 1600 JST** |
| 2 | + |
| 3 | +[Link](https://www.worldtimebuddy.com/?qm=1&lid=14,12,1850147&h=14&date=2025-7-30&sln=8-9&hf=1) to meeting time in common time zones. |
| 4 | + |
| 5 | +| Search Key | Description | |
| 6 | +| ----- | ----- | |
| 7 | +| \[todo\] | Action Item | |
| 8 | +| \[decision\] | Something decided on | |
| 9 | +| \[important\] | Key information | |
| 10 | + |
| 11 | +## **Agenda** |
| 12 | + |
| 13 | +1. Solicitation of notetaker |
| 14 | +2. Acceptance of [Previous Meeting Minutes](https://github.com/rustfoundation/safety-critical-rust-consortium/blob/main/subcommittee/coding-guidelines/meetings/2025-07-22/minutes.md) |
| 15 | +3. Introduction of new members |
| 16 | +4. Infrastructure |
| 17 | + * [New Issue to PR system is live](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/pull/122) |
| 18 | + * [More than one pair of examples per guideline](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/issues/141) |
| 19 | +5. Review progress on guidelines incorporated from CERT |
| 20 | + * [High-level mapping of CERT rule groups to Rust](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/issues/152) |
| 21 | + * [INT34-C](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/issues/156) adoption |
| 22 | +6. Checked arithmetic guidelines |
| 23 | + * [Division by zero](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/pull/132) |
| 24 | + * [Checked arithmetic operations](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/pull/136) |
| 25 | + * [Use of the `unchecked` APIs](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/issues/148) |
| 26 | +7. Other reviews |
| 27 | + * [Recursive functions](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/issues/135) (ready to merge \- test signoff system) |
| 28 | +8. Emergent discussions: |
| 29 | + * From checked arithmetic: rules about `unsafe` (part of the [overall guideline strategy w.r.t “defects” vs “subsets”](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/issues/142)) |
| 30 | + * [From matching types at the language boundary](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/issues/137) |
| 31 | + * [Rules about `panic`](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/issues/158) |
| 32 | + * From INT36-C adoption: New section for pointers and provenance (affects [ordering](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/issues/157)) |
| 33 | +9. Round table |
| 34 | + |
| 35 | +## **Check-in area** |
| 36 | + |
| 37 | +**Please add your name, and an emoji that describes your day.** |
| 38 | + |
| 39 | +* Alex Celeste ☕ |
| 40 | +* Fernando Jose ☕ |
| 41 | +* Achim Kriso 🐦 |
| 42 | +* Christof Petig 🚲 |
| 43 | +* Tiago Manczak |
| 44 | + |
| 45 | +**Notetaker:** |
| 46 | + |
| 47 | +* Fernando |
| 48 | + |
| 49 | +For tips on how we take notes in the Safety-Critical Rust Consortium, please see the [Meeting Notetaker Role](https://github.com/rustfoundation/safety-critical-rust-consortium/blob/main/docs/notetaker-role.md) doc. |
| 50 | + |
| 51 | +## **Housekeeping section** |
| 52 | + |
| 53 | +* Document space: [coding-guidelines](https://github.com/rustfoundation/safety-critical-rust-consortium/tree/main/subcommittee/coding-guidelines) |
| 54 | +* Zulip: [safety-critical-consortium: Coding Guidelines](https://rust-lang.zulipchat.com/#narrow/channel/445688-safety-critical-consortium/topic/Coding.20Guidelines) |
| 55 | +* [Early Alpha Milestone](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/milestone/1) |
| 56 | + |
| 57 | +## **Tasks** |
| 58 | + |
| 59 | +* Search for the \[todo\] markers |
| 60 | + |
| 61 | +## **Meeting Minutes** |
| 62 | + |
| 63 | +* Approval of previous minutes. |
| 64 | +* No new people introduced. |
| 65 | +* Infrastructure topic, more than one pair of examples per guideline. Mention the other infrastructure topic. |
| 66 | +* CERT guidelines. |
| 67 | + * Unless we overlooked, it appeared that guidelines corresponding to CERT INT32-C and INT35-C hadn't been added. |
| 68 | + * Taking a look at [the issue inspired by INT34-C](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/issues/156). Call for comments. |
| 69 | + * It is asked if this is already covered by the checked arithmetic guideline. Encouraged to comment on the issue. A comment will be added \[todo\]. |
| 70 | + * Taking a look at [the issue about categorization](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/issues/152). Call for comments. No comments. |
| 71 | + * Taking a look at the checked arithmetic and division by zero pull requests. Discussion on the overlap, which comes from the CERT rules. |
| 72 | + * [Discussing the issue about unchecked](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/issues/148) |
| 73 | + * Stemming from [the comment about unsafe](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/issues/148#issuecomment-3089428786): subset-oriented approach and unsafe. Different approaches are possible based on how to deal with unsafe (blocks). |
| 74 | + * Historical context about the use of unsafe added. 3rd party code in cybersecurity. Probably wanted to ban unsafe in that case. In functional safety, differently, "everything is under control". Then, there are interesting categories relating to drivers and what the actual definition of unsafe is; beyond the Rust definition? All in all, avoiding unsafe is desired, but banning it totally is going too far. It would rather be desired to push it to the bottom of the code. A follow-up comment: there will be rules (guidelines) which are only sensible to apply in the context of unsafe. |
| 75 | + * It’s suggested to refrain from considering the unchecked operations in insolation \[important\]. |
| 76 | + * [https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/issues/137](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/issues/137) |
| 77 | + * Recommendation to only use types without fixed bitwidths at the language boundaries. But, is it practical? |
| 78 | + * [https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/issues/158](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/issues/158) |
| 79 | + * [Similar in CERT C++](https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=88046339) |
| 80 | + * Call for comments on a new section for pointers and provenance. |
| 81 | + * It sounds good. It is suggested that provenance isn’t part of integers. It can be part of unsafe, noting that the unsafe section may become rather large. |
| 82 | + * [https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/issues/135](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/issues/135) |
| 83 | + * Looks like it is in a good state. Should it be moved to the new system? We start doing it during the meeting. Adding the label. The action is triggered and a [pull request](https://github.com/rustfoundation/safety-critical-rust-coding-guidelines/pull/159) opened. It looks like a good start, although the code example may have not been copied over correctly \[todo\] |
| 84 | + * Round table |
| 85 | + * About panics, in addition to static analysis, since they’re in a way similar to unsafe, would it be feasible to use a way similar to what’s used for unsafe? In terms of documentation, justifying it the panicking state. |
| 86 | + * An initial reaction is checked exceptions. |
| 87 | + * Maybe there’s wording for it already in SAE. |
| 88 | + |
| 89 | +## **Material** |
| 90 | + |
| 91 | +Any material to read before the meeting should be included here. |
| 92 | + |
| 93 | +### **GitHub Project Board for Work Items** |
| 94 | + |
| 95 | +* [Work Item Board](https://github.com/orgs/rustfoundation/projects/1) |
| 96 | + |
0 commit comments