[Coding Guideline]: Do Not Depend on Function Pointer Identity by rcseacord · Pull Request #256 · Safety-Critical-Rust-Consortium/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.

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

+
+    - 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)

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.

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

+      :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

+          #[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

+      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

+              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

+          #![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.

github-actions · 2026-03-25T15:22:41Z

🔔 Transition Period Ended

@vccjgust, the 14-day transition period has passed without activity on this review.

Per our contribution guidelines, this may result in a transition from Producer to Observer status.

The review will now be reassigned to the next person in the queue.