How should we handle raw function pointers?

Open
  • Is something wrong?
#4,998 6 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
rust
Domain
operating-systems

Research direction

Start with the proposed FfiSafeFn and RawFnPointer design in this issue, then read the linked Rust Zulip discussion and related issue #1637. Determine whether the wrapper safely represents function pointers with integer sentinels and whether a public API is appropriate; done means reaching and documenting a settled design.

Written by the indexing model from the issue text.

Description

C-discussion

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:

use core::mem::MaybeUninit;

/// Also acts as `Sealed`. Mostly serves as a lint within libc that we don't forget
/// the `unsafe extern "C"`.
/// 
/// # Safety
/// Only implement on `unsafe extern "C"` function pointers. `Option<Self>` must
/// be the same size as `Self`.
unsafe trait FfiSafeFn: Copy {}

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

/// Has the same repr as `F`. Alternatively, maybe a union between `Option<F>` and `usize`?
#[allow(private_bounds)]
#[repr(transparent)]
#[derive(Clone, Copy, Debug)]
pub struct RawFnPointer<F: FfiSafeFn>(MaybeUninit<Option<F>>);

#[allow(private_bounds)]
impl<F: FfiSafeFn> RawFnPointer<F> {
    // Internal helper, not public.
    const fn from_int(val: usize) -> Self { /* ... */ }
}

/* Maybe? To make constructing easier.
 *
 * Free functions to avoid breakage if `RawFnPointer` can become an alias
 * in the future. */

/// # Safety
///
/// Must point to a valid function.
#[allow(private_bounds)]
pub unsafe fn raw_to_fn_pointer<F: FfiSafeFn>(f: RawFnPointer<F>) -> F {
    unsafe { f.0.assume_init().unwrap() }
}

#[allow(private_bounds)]
pub fn raw_from_fn_pointer<F: FfiSafeFn>(f: F) -> RawFnPointer<F> {
    RawFnPointer(MaybeUninit::new(Some(f)))
}

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 https://github.com/rust-lang/libc/issues/1637

Dominant language
Rust
Stars
2.6k
Forks
1.3k
Avg merge
2d 13h
Merged PRs (30d)
27

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from rust-lang/libc

All issues in rust-lang/libc

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.