Decide on the validity of function pointers

[RalfJung]

We decide

that the validity invariant for function pointers is: they need to be non-null.

Transmuting any provenance-free non-null input to a function pointer is definitely allowed without causing immediate UB.
When and whether these function pointers can actually be invoked is a different question and not answered here.

We do not decide what happens when the input has provenance. This is tracked here. In particular, values such as &0 (that have provenance) might or might not be legal to transmute to function pointers.

Rationale

The non-null requirement is already out there since forever and plenty of code relies on Option<fn()> having a null niche, so that part is not up for debate any more.

We considered requiring function pointers to be aligned to some target-specific alignment. However, for all currently supported targets, that alignment would be 1. (Note that even on ARM, where functions have alignment requirements, the lowest bit is used to indicate Thumb mode. So while functions are aligned, function pointers are not.) Furthermore, C clearly allows casting 0 to function pointers; it will be hard to argue that casting 1 or -1 to a function pointer is UB in C, so a target that makes alignment requirements for function pointers a validity concern is likely to be incompatible with C. Common practice conforms this: for instance, 1 is a common value for SIG_IGN which is cast to a function pointer to be stored in the sa_handler field of sigaction -- and while a new target could of course pick a higher-aligned value for SIG_IGN, there is likely more C code out there using various sentinel values. SQLite uses -1 as a sentinel. Even Rust code using 1 as a sentinel function pointer has been spotted in the wild.

Examples

The following pieces of code cause UB (as in, the UB arises when executing the code, not just potentially later):

let _val: fn() = MaybeUninit::uninit().assume_init();

let _val: fn() = mem::transmute(0usize);

The following piece of code is well-defined:

let val: fn() = mem::transmute(1usize);
// Note that safe code can cause UB with `val`!
// This operation is not sound, but it is well-defined.
// It violates only the safety invariant of `fn()`,
// not its validity invariant.

The following is not decided by this FCP:

let ptr = &0i32;
let ptr_to_ptr = addr_of!(ptr).cast::<usize>();
ptr_to_ptr.cast::<fn()>().read(); // pointer-to-fnptr transmutation -- UB or not?

The following functions are sound (as in, safe code invoking these functions can never have UB):

fn to_fn_then_discard(x: usize) {
  if x == 0 { return; }
  let f: fn() = unsafe { mem::transmute(x) };
  // Calling `f` would be very unsound, but just creating this pointer and then never using it is fine.
  drop(f);
}

Prior discussion

• Validity of function pointers #72
• When can function pointers be transmuted? #81

[CAD97]

While I did make the argument to not bundle this with the other simple validity, I have no concerns with this actually being the validity requirement for function pointers. Even in the mentioned case where ABI expects function pointers to be aligned (say, to pack bool arguments as logically part of the ABI rather than part of the pointer), this can be made to be a requirement of the ABI rather than directly of function pointer layout.

[RalfJung]

Now again with T-opsem label...
@rfcbot merge

[rfcbot]

Team member @RalfJung has proposed to merge this. The next step is review by the rest of the tagged team members:

• @CAD97
• @JakobDegen
• @RalfJung
• @digama0
• @saethlin

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[RalfJung]

Added to our FCP list of "decisions we made", so the issue can be closed.