Stream: project-ffi-unwind

Topic: #[ffi_no_unwind]


view this post on Zulip gnzlbg (Oct 24 2019 at 07:32):

I think a #[ffi_no_unwind] attribute for FFI declarations only would be ok

view this post on Zulip gnzlbg (Oct 24 2019 at 07:32):

For extern "C" fn foo() { ... } definitions in Rust, the attribute should not be necessary

view this post on Zulip gnzlbg (Oct 24 2019 at 07:32):

Since the compiler should be able to properly deduce whether that function can or cannot be nounwind

view this post on Zulip gnzlbg (Oct 24 2019 at 07:37):

Semantically, those who want to make those extern "C" Rust definitions abort can already do so by just using catch_unwind, so while we could add a "proc macro" that does it for them, it shouldn't be necessary for an MVP

view this post on Zulip gnzlbg (Oct 24 2019 at 07:38):

The MVP could just be "unwinding from extern "C" is ok, and for extern "C" declarations only there is a #[ffi_no_unwind] attribute that you can use."

view this post on Zulip gnzlbg (Oct 24 2019 at 07:39):

The "unwinding from extern "C" is ok" guarantee could be worded carefully, to say that it unwinds with a platform unwind, meaning that we on paper "translate" a Rust unwind to a platform unwind, so that this does not stabilize nor constrain the Rust unwind implementation details.


Last updated: Jan 26 2022 at 08:21 UTC