SQLite's API requires passing a
-1isize as a
Option<unsafe extern "C" fn(a: *mut c_void)>: https://www.sqlite.org/c3ref/c_static.html in some cases. Transmuting between these works, but it gives me the heebie jeebies and I suspect it's unsound...
I don't think rust code ever needs to call this, so I suspect we might be able to override bindgen and just use a repr(transparent) wrapper (I guess in theory a platform exists where isize and function pointers have a different ABI, but... realistically...)
You shouldn't need to transmute; you should be able to convert to usize and then to a fn type like any other pointer.
"With the proposed wording for a future RFC, the only value you can't assign to a function pointer is 0, all other values are ok." ... but this hasn't actually been accepted yet
@comex hm? I'm not sure I follow what you mean by "and then to a fn type like any other pointer" -- I can't do
some_usize as unsafe extern "C" fn(a: *mut c_void).
fn ptrs in Rust are safe to call and thus not safe to cast from. there are no raw fn ptrs.
@Thom Chiovoloni ah, you basically want https://github.com/rust-lang/unsafe-code-guidelines/pull/197 I think
Hmm, so AFAICT it's not strictly well defined, but there are no plans to make it UB (just the opposite) so I... probably am just not going to worry about it too much, since I don't have a lot of choice wrt using this API.
so right now it is well-defined if and only if fn ptrs have no alignment restrictions on your platform
oh lol that actually doesnt even mention fn ptr alignment and just makes it well-defined
which I think is because all platforms we currently support do not make alignment requirements for fn ptrs
but we have no RFC that this cannot change in the future
if function pointers have an alignment restriction, the original C API doesn't work either :)
or rather, is undefined behavior in C
(it might still work)