`ptr::fn_code_ptr` for explicitly getting an opaque pointer of a function

[pitaj]

Proposal

Problem statement

Currently, the only way to get the address of a function pointer is using the as operator. But because as is heavily overloaded, this can result in unfortunate mistakes that are silently accepted.

Motivating examples or use cases

There was recently a real bug caused by the following code:

len < u16::max as usize

This was meant to refer to u16::MAX, the associated constant with value 0xFFFF, but instead returns the address of the function pointer to u16::max.

We would like to add a general lint for this form of as cast, but it can't be enabled by default without an alternative way of getting the address of a function pointer.

Solution sketch

// core::ptr

extern type CodeInner;

// Is there a way to prevent people from implementing traits for this?
// Would be nice if we could reserve the ability to just make this an alias to unit.
#[repr(transparent)]
pub struct Code(CodeInner);

pub fn fn_code_ptr<T: FnPtr>(f: T) -> *const Code { ... }

Then the lint can suggest doing a two-step conversion:

warning: casting directly to function address is error-prone
   |
11 | if x <= u16::max as usize {
             ^^^^^^^^^^^^^^^^^
cast to a code pointer first, then get the address
   |
11 | if x <= core::ptr::fn_code_ptr(u16::max).expose_provenance() {

Alternatives

We could just stabilize FnPtr::addr directly, but that trait is meant to be for internal use only.

We could provide a function that casts directly from a function pointer to usize, but there are concerns around code pointer vs data pointer sizing. This way, the programmer can explicitly choose what address operation to use: .addr() or .expose_provenance().

Links and related work

• IRLO discussion: https://internals.rust-lang.org/t/as-cast-in-a-real-vulnerability/22918
• CVE-2025-1014 bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1940804

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.

[programmerjake]

what happens on targets where code pointers are larger than data pointers (so larger than usize)? are we just deciding rust doesn't support them?

[pitaj]

Good question, I hadn't considered that case. Does fn_addr_eq support those cases?

I see a few options:

1. truncate to usize, just like how u16::max as usize works today
2. don't provide ptr::fn_addr on those platforms
3. use a type alias like the following:

// core::ptr

cfg_match! {
    some_platform_with_wide_code_pointers => {
        pub type CodePtrAddr = u64;
    }
    _ => {
        pub type CodePtrAddr = usize;
    }
}

pub fn fn_addr<T: FnPtr>(f: T) -> CodePtrAddr {
    f.code_ptr_addr() // the `*const ()` returned by `FnPtr::addr` is probably a data pointer?
}

[programmerjake]

an example target that has wider code than data pointers is msp430, it can have 20-bit code pointers (stored in 32-bits) and 16-bit data pointers. https://downloads.ti.com/docs/esd/SLAU132/data-types-stdz0555922.html#SLAU1326246

16-bit x86 also can have that in medium mode.

[programmerjake]

Does fn_addr_eq support those cases?

idk, but there's no API reason it can't.

3. use a type alias like the following:

I think that's the best option.

[hanna-kruppe]

Does Rust currently support any targets that would require a larger type than usize to represent a function pointer? (Or would require a larger usize specifically to enable converting a function pointer to usize and back?) If not, this bridge could be crossed later: all the options discussed above would keep the return type identical to usize on platforms where it works.

Having a type alias "proactively" would theoretically enable code to be future compatible with the introduction of targets where it's not usize. However, since such targets are extremely niche and even most C code routinely assumes {,u}intptr_t can represent function pointers (does standard C even have a better type for it?), so I don't expect a lot of Rust code to go out of its way to accomodate this. Especially if there's no target you could compile for to even test if even you got it right: type CodePtrAddr = usize; does nothing to prevent you from mixing and matching with usize by accident.

[ptrca]

I don't say that the proposing function is not useful. However the motivating example is a bit off.

There was recently a real bug caused by the following code:

len < u16::max as usize
This was meant to refer to u16::MAX, the associated constant with value 0xFFFF, but instead returns the address of the function pointer to u16::max.

So does this means u16::max as usize should trigger a compiler warning/error now?

[programmerjake]

Does Rust currently support any targets that would require a larger type than usize to represent a function pointer?

AFAICT, no:

• AVR -- AFAIK neither GCC nor LLVM support more than 16-bit data/code pointers.
• MSP430 -- GCC's code size selection options seems to switch all code/data pointer sizes together, LLVM seems to have only implemented 16-bit so far.
• There's no 16-bit x86 target, and even if there were it would probably be the same as GCC's -m16 option which basically treats it like a 32-bit cpu but just emits address (0x67) and data size (0x66) override prefixes on all the appropriate instructions.
• AFAIK the GCC targets aren't far enough along that anyone's using the weird address size targets.

[pitaj]

So does this means u16::max as usize should trigger a compiler warning/error now?

Specifically, I intend to move the clippy lint fn_to_numeric_cast_any from restriction to pedantic. And eventually I'd like to start moving the various pedantic clippy lints for as-casts to be warn by default.

[scottmcm]

One thing that comes to mind here: if there's concern around going right to the integer, maybe we could instead have a function for function-item to function-pointer?

Going to isize::max.as_fn() as usize or something might be a reasonable option too, without having to actually write out the whole fn(_, _) -> _ that's a bit too annoying (imho) to be the suggested fix.

---

So does this means u16::max as usize should trigger a compiler warning/error now?

Lang and Libs-api have agreed in principal to move in that direction, yes. It just needs functions -- like the one proposed here -- for the rustc lints to point to instead for the cases where someone actually wanted that.

Basically, for things that change something to a different category, it'd be good to have named methods instead of as.

[tgross35]

Agreed that we should try to return some kind of pointer here because it avoids tricky provenance questions. It's not clear at the moment whether or not function pointers have provenance (rust-lang/unsafe-code-guidelines#340), but the docs for .addr() currently say that casting the result usize a pointer then derefing is UB. Seems like an easy potential footgun without an opsem decision that function pointers are an exception. (If anything, maybe a usize API should call .expose_provenance() instead?)

[pitaj]

I've edited the original proposal to .expose_provenance() instead of .addr() as I forgot that's the actual equivalent to as casts.

Returning a pointer would mean the API could never support platforms where code pointers are larger than data pointers. That's probably fine.

I'm not exactly sure what to call that; I don't think it should be called addr. Maybe:

// core::ptr

pub fn fn_unit_ptr<T: FnPtr>(f: T) -> *const () {
    f.addr()
}

[Amanieu]

I would prefer seeing a more complete API that handles both converting fn() to pointers and pointers back to fn(). Currently the only way to perform the reverse operation is via transmute which is a very big hammer.

Here's what I have in mind (as an extension of the existing unstable FnPtr trait):

// General extern type to indicate a pointer to code.
// This is useful since it makes APIs more type-safe by avoiding mixing code and data pointers accidentally.
// It is optional an could be replaced with just ().
extern type Code;

trait FnPtr {
    fn addr(self) -> usize;
    fn as_ptr(self) -> NonNull<Code>;
    unsafe fn from_ptr(NonNull<Code>) -> Self;
}

let ptr = my_fn.as_ptr();
let my_fn2 = <fn(i32) -> i32>::from_ptr(ptr);

[programmerjake]

I quite like extern type Code, since that means a future version of rust that has a target that needs a different number of bits for code pointers can just make that a lang item and special-case all pointers to Code to be the correct size. or, when rust decides fn() should be an unsized type representing the actual function's code and function pointers are instead &'static fn(), then Code can just be a type alias for fn(!)