Skip to content

How should we handle raw function pointers? #4998

@tgross35

Description

@tgross35

There are a handful of cases where we have something that is canonically a function pointer, but also accepts integer values (sigaction-related items are one example). Just using usize/size_t works but it loses that type information. We have Option<extern "C" fn(...) -> ...> in some cases, but that makes stumbling into UB too easy if the API expects integer sentinels.

What we really need is raw function pointers, but that would be a long way away. See #t-lang > Function pointers that work like references.

I'm thinking maybe we should add a wrapper type to help out here:

// Also acts as `Sealed`. Mostly serves as a lint within libc that we don't forget
// the `unsafe extern "C"`.
unsafe trait FfiSafeFn {}

impl<T1, U> FfiSafeFn for unsafe extern "C" fn(T1) -> U {}
impl<T1, T2, U> FfiSafeFn for unsafe extern "C" fn(T1, T2) -> U {}
impl<T1, T2, T3, U> FfiSafeFn for unsafe extern "C" fn(T1, T2, T3) -> U {}

/// Has the same repr as `F`
#[allow(private_bounds)]
#[repr(transparent)]
#[derive(Clone, Copy, Debug)]
pub struct RawFnPointer<F: FfiSafeFn>(MaybeUninit<Option<F>>, PhantomData<F>);

impl RawFnPointer {
    /// Internal helper.
    const fn from_int(val: usize) -> Self;
}

// Maybe? To make constructing easier
impl<F: FfiSafeFn> From<F> for RawFnPointer<F> { /* ... */ }

pub unsafe fn get_raw_fn_ptr(a: 

With the intent being that users would have to transmute to a function pointer if they know it is valid and want to call it. This isn't any worse than what needs to happen in places where we use usize, though constructing is less convenient.

If we don't provide any public API then we would hopefully have a path to change this to a typedef in a future where raw function pointers exist.

For now this is probably only likely to be used in places where we know we might have sentinel values, though in the ideal world we'd use it everywhere.

Related background at #1637

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-discussionCategory: Discussion or questions that doesn't represent issues with `libc`.

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions