`ptr::fn_addr`

[WaffleLapkin]

Proposal

Problem statement

There is no alternative to the error-prone "fn-ptr to integer" casts. In rust-lang/rfcs#3526 I'm proposing to remove "fn-ptr to integer" casts in the future edition, but that requires there to be an alternative to them.

Motivating examples or use cases

It is relatively easy to accidentally cast a function to an integer, for example:

let size = mem::size_of::<T> as u32; // Note: no `()`, this casts the function, not its return value!

Thus it is desirable to forbid (or warn on) such casts. But to do so, there should be an alternative for cases which actually want to get an address of a function:

some_weird_api(f as usize);
// I could not come up with an example, but surely there are some use-cases
// like maybe giving the address to inline asm or to disassembler api or something...

Solution sketch

// core::ptr

pub fn fn_addr<F: FnPtr>(f: F) -> usize {
    f.addr().addr()
}

some_weird_api(fn_addr(f));

This seems consistent with already stable ptr::fn_addr_eq
and provides a way to get a function address without stabilizing the internal FnPtr trait.

Alternatives

• Suggest f as *const () as usize or (f as *const ()).addr() instead
  • using a data pointer seems weird, non-obvious, and awkward
• Use a new trait instead of FnPtr, such that FnDefs could also be passed without being casted to function pointers
  • that is, allow fn a() {}; fn_addr(a); without requiring fn_addr(a as fn())

Links and related work

• Add forbidden function casts RFC rfcs#3526
• Split out common behavior of FnStatic and FnPtr into a new trait: FnAddr #837
• function_casts_as_integer lint
• core::ptr::fn_addr_eq

What happens now?

This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

Possible responses

The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):

• We think this problem seems worth solving, and the standard library might be the right place to solve it.
• We think that this probably doesn't belong in the standard library.

Second, if there's a concrete solution:

• We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
• We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.

[tgross35]

There is rust-lang/rust#148768, but it doesn't have an implementation yet.

[WaffleLapkin]

I feel like with even with rust-lang/rust#148768 it would still be nice to have ptr::fn_addr for more discoverability, consistency with fn_addr_eq, and potentially easier stabilization path than the full traits.

I would also propose to then split-off the address part of the traits, so there is a trait that is implemented for both function pointers and function defs:

// Implemented for function pointers and types that coerce to function pointers
pub unsafe trait FnAddr {
    fn addr(self) -> usize;
    fn as_ptr(self) -> NonNull<Code>;
} 

// Implemented only for function pointers.
pub unsafe trait FnPtr: FnAddr {
    unsafe fn from_ptr(NonNull<Code>) -> Self;
}

// Implemented for all types that coerce to function pointers.
pub unsafe trait FnStatic<Args>: Fn<Args> + FnAddr {
    type FnPtr: FnPtr;
    fn as_fn() -> Self::FnPtr;
    extern "rust-call" fn call_static(args: Args) -> Self::Output;
}

pub fn fn_addr<F: FnAddr>(f: F) -> usize {
    f.addr()
}

[pitaj]

Prior ACP #589

[joshtriplett]

No objection to having fn_addr as well for discoverability, but it'd be nice to have a method available (e.g. via a stable trait, whether stabilizing the current trait or a new one).

Is there something that prevents us from stabilizing FnPtr (as a presumably sealed trait)?

[tgross35]

Is there something that prevents us from stabilizing FnPtr (as a presumably sealed trait)?

The fact that it doesn't exist is probably a speedbump 🙂 but I think that's reasonable to revisit after rust-lang/rust#156176 has been around for a small bit of time.

[tgross35]

I stand corrected, it does exist but isn't linked https://doc.rust-lang.org/std/marker/trait.FnPtr.html. rust-lang/rust#156176 is just making that work for the ACP's design guidelines (which is probably still a blocker)

[joshtriplett]

Reviewing #589, having the opaque Code type seems like a reasonable approach here. We still need the mechanism to obtain a usize though, as well.

The approach @WaffleLapkin suggests in #836 (comment) seems great to me.

[tgross35]

The approach @WaffleLapkin suggests in #836 (comment) seems great to me.

I'm also a fan of having the common behavior extracted, maybe this is worth a separate ACP @WaffleLapkin?

(Implementation-wise it's probably easiest to let rust-lang/rust#156176 get through first before changing anything, since that does a bit of lifting to get Code working)

[WaffleLapkin]

Opened #837, as suggested by @tgross35