[Coding Guideline]: Do Not Depend on Function Pointer Identity by rcseacord · Pull Request #256 · rustfoundation/safety-critical-rust-coding-guidelines

rcseacord · 2025-12-06T18:28:04Z

Coding guidelines based on #255

netlify · 2025-12-06T18:28:09Z

✅ Deploy Preview for scrc-coding-guidelines ready!

Name	Link
🔨 Latest commit	`3242afc`
🔍 Latest deploy log	https://app.netlify.com/projects/scrc-coding-guidelines/deploys/697fe7ca8312120008ec298f
😎 Deploy Preview	https://deploy-preview-256--scrc-coding-guidelines.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

src/coding-guidelines/types-and-traits.rst

programmerjake · 2025-12-06T21:09:48Z

src/coding-guidelines/types-and-traits.rst

+
+    - Comparing function pointers for equality (``fn1 == fn2``)
+    - Assuming a unique function address
+    - Using function pointers as identity keys (e.g., in maps, registries, matchers)


you can still use function pointers as keys, they just don't have a one-to-one relationship to function items, so you can't rely on a function item giving the same function pointer or different items giving different pointers. (ignoring #[no_mangle]). so e.g. you can have a HashSet<fn()> and it works just fine as long as you don't assume inserting any particular function item does anything other than guaranteeing calling one or more of the entries is equivalent to calling that function item.

felix91gr · 2025-12-15T17:32:28Z

@rcseacord you'll want to consider this discussion before the guideline is ready for merge rust-lang/unsafe-code-guidelines#589, since it addresses the same topic

PLeVasseur · 2025-12-15T18:18:59Z

FYI @rcseacord @manhatsu -- I got this building again, aside from the code examples, see: #287

Feel free to just yoink the commit from there and replace the commits on this feature branch (i.e. cherry-pick that commit I linked above onto your local updated main, then force-push to your remote branch).

That way we keep all the comment history from on here.

(The coding examples also need to be updated to compile)

src/coding-guidelines/types-and-traits/gui_QbvIknd9qNF6.rst.inc

Clarify function pointer stability issues and provide examples of potential problems and compliant solutions.

Added a non-compliant example demonstrating issues with function address stability and uninitialized memory in Rust.

Updated references and clarified text regarding function pointer stability and the implications of using `#[no_mangle]` functions. Added citations for better context and understanding.

Refactor handler registration to pass mutable vector.

Clarify guideline on function pointer comparison and provide examples of indirect comparisons.

github-actions · 2026-02-10T23:08:39Z

👋 Hey @vccjgust! You've been assigned to review this coding guideline PR.

Your Role as Reviewer

As outlined in our contribution guide, please:

Begin your review within 14 days
Provide constructive feedback on the guideline content, examples, and formatting
Iterate with @rcseacord - they may update the PR based on your feedback
When the guideline is ready, approve and add to the merge queue

Review Checklist

Guideline title is clear and follows conventions
Amplification section expands on the title appropriately
Rationale explains the "why" effectively
Non-compliant example(s) clearly show the problem
Compliant example(s) clearly show the solution
Code examples compile (check the CI results)
FLS paragraph ID is correct

Bot Commands

If you need to pass this review:

@guidelines-bot /pass [reason] - Pass just this PR to the next reviewer
@guidelines-bot /away YYYY-MM-DD [reason] - Step away from the queue until a date
@guidelines-bot /release [@username] [reason] - Release assignment (yours or someone else's with triage+ permission)

To assign someone else:

@guidelines-bot /r? @username - Assign a specific reviewer
@guidelines-bot /r? producers - Request the next reviewer from the queue

Other commands:

@guidelines-bot /claim - Claim this review for yourself
@guidelines-bot /label +label-name - Add a label
@guidelines-bot /label -label-name - Remove a label
@guidelines-bot /queue - Show reviewer queue
@guidelines-bot /commands - Show all available commands

plaindocs · 2026-02-18T15:11:04Z

Hey @vccjgust would you like to claim this review, or let someone else grab it?

vccjgust · 2026-02-18T18:04:24Z

@guidelines-bot /claim

github-actions · 2026-02-18T18:04:42Z

✅ @vccjgust has claimed this review.

@vccjgust is designated as reviewer by queue rotation, but GitHub could not add them to PR Reviewers automatically (API 422). A triage+ approver may still be required before merge queue.

vccjgust · 2026-02-18T18:05:40Z

Hi @plaindocs, sorry didn't know it needed claiming since it was already assigned to me (or so I thought). I'm taking a look at it as we speak! 😃

plaindocs · 2026-02-18T18:49:08Z

No worries @vccjgust, we're just ironing out some kinks in the process and I wasn't sure you'd received the notification.

vccjgust

Looks great! I have a few small comments. I'm not sure what to do about many of the non-compliant examples since they actually work fine when run as-is in Rust Playground. It would of course be best if we could come up with demonstrators that actually show case the unexpected behaviour, but I'm not sure how to do that given that it relies on cross-crate linking behaviour etc.

vccjgust · 2026-02-18T19:15:58Z

src/coding-guidelines/types-and-traits/gui_QbvIknd9qNF6.rst

+      :status: draft
+
+      In this noncompliant example, the ``write_first`` and ``write_second`` functions each
+      initialize one field within a ``MaybeUninit`` and write ``uninit`` to the other. If


MaybeUninit -> MyMaybeUninit? It is easy for the reader to confuse this with Rust's own MaybeUninit. Perhaps rename to something a bit more unambiguous?

vccjgust · 2026-02-18T19:50:27Z

src/coding-guidelines/types-and-traits/gui_QbvIknd9qNF6.rst

+          #[no_mangle]
+          fn write_first(a: &mut MyMaybeUninit) {
+              *a = MyMaybeUninit { init: (0, 1, 2, 3) };
+              *a = MyMaybeUninit { uninit: () };


I'm a bit confused what this is intended to show since the uninit field is zero sized, so writing to it won't actually change the bit pattern (i.e. this gets compiled down to nothing)

vccjgust · 2026-02-18T19:53:29Z

src/coding-guidelines/types-and-traits/gui_QbvIknd9qNF6.rst

+      function or alter the address at which it is emitted.
+
+      Consequently, the following operations are unreliable for functions which are not
+      ``#[no_mangle]``:


The non-compliant example with MyMaybeUninit below shows that even #[no_mangle] can get merged into one

vccjgust · 2026-02-18T19:57:12Z

src/coding-guidelines/types-and-traits/gui_QbvIknd9qNF6.rst

+              a.init.3 = 3;
+          }
+
+          #[no_mangle]


the 2024 edition will insist to use unsafe all over the place here. How do we show that this only compiles for <2024 edition?

vccjgust · 2026-02-18T20:15:36Z

src/coding-guidelines/types-and-traits/gui_QbvIknd9qNF6.rst

+          #![allow(unpredictable_function_pointer_comparisons)]
+
+          mod crate_a {
+              pub fn handler_a() {}
+              pub fn handler_b() {}
+          }
+
+          fn dispatch(f: fn()) {
+              if f == crate_a::handler_a {
+                  println!("Handled by A");
+              } else if f == crate_a::handler_b {
+                  println!("Handled by B");
+              }
+          }
+
+          fn main() {
+              dispatch(crate_a::handler_a);


I'm not sure how to demonstrate this issue properly here, but this example as it is currently written, behaves exactly as expected when running in Rust Playground (at least for me)

github-actions · 2026-02-23T20:20:46Z

✅ Rectified PR #256: latest review by @vccjgust is COMMENTED; refreshed reviewer activity.

github-actions · 2026-03-11T14:36:42Z

⚠️ Review Reminder

Hey @vccjgust, it's been more than 14 days since you were assigned to review this.

Please take one of the following actions:

Begin your review - Post a comment with your feedback
Pass the review - Use @guidelines-bot /pass [reason] to assign the next reviewer
Step away temporarily - Use @guidelines-bot /away YYYY-MM-DD [reason] if you need time off

If no action is taken within 14 days, you may be transitioned from Producer to Observer status per our contribution guidelines.

Life happens! If you're dealing with something, just let us know.

rcseacord mentioned this pull request Dec 6, 2025

[Coding Guideline]: Do Not Depend on Function Pointer Identity Across Crates #255

Open