Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support function pointer type #57

Open
vimirage opened this issue Jul 24, 2022 · 3 comments
Open

Support function pointer type #57

vimirage opened this issue Jul 24, 2022 · 3 comments

Comments

@vimirage
Copy link

vimirage commented Jul 24, 2022

Upstream issue: denoland/deno#15292.
Downstream issue: libffi/libffi#725.

It seems that libffi-rs doesn't provide a function pointer type, but after further investigation, it seems that this is because the C libffi does not support this, so I have opened an issue there too; feel free to subscribe to the downstream issue.

Nonetheless, in the meanwhile, it does seem that libffi-rs misuses *const c_void as fn(), which can still be fixed here.

See https://rust-lang.github.io/unsafe-code-guidelines/layout/function-pointers.html and https://c-faq.com/ptrs/generic.html.

Rust claims that Rust's extern "ABI" fn(...) -> R has the same size/alignment/etc. as C's void (*)(), and that it may not necessarily map to C's void *.

Furthermore, Rust's fn documentation requests that code use fn primitives for FFI.

As a result, some present usage here is unsound (on some platforms), such as https://docs.rs/libffi/latest/libffi/low/struct.CodePtr.html.

@yorickpeterse
Copy link
Collaborator

@phosra Out of curiosity, on what platforms would this be unsound?

@vimirage
Copy link
Author

vimirage commented Jul 25, 2022

@phosra Out of curiosity, on what platforms would this be unsound?

Admittedly, such platform would likely be a Harvard architecture platform that doesn't implement POSIX - in practice... it's very unlikely to encounter such a platform, even less so for one with different sizes.

Although, it's possible to find maybe a Harvard embedded platform? How that could possibly affect FFI, I suppose it could be useful for interacting with native code after developing and running a new scripting language compiled as a bytecode, such as is done for JavaScript via XS, or Python via CircuitPython.

More realistically, although I cannot quite determine whether it's so, but a (future) CHERI Aarch64 Harvard, platform running an OS that doesn't implement POSIX could run into such an issue... still amusingly unlikely!

It's more of a "technical" issue. :)

@markcsaving
Copy link

markcsaving commented Jul 28, 2023

@phosra

You are correct that a function pointer cannot necessarily be converted to and from a void*. The C standard explicitly details when it is acceptable to convert between pointer types, and there is nothing saying a function pointer can be converted to and from void*. However, the documentation for the C libffi library, which this crate is a wrapper of, explicitly states that on any platform where closures are supported, you can convert certain void*s produced by the library into function pointers. See the manual here. If this is broken, it is a problem on the C library's side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants