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

Functions that do not own types implementing Drop #11

Open
gnzlbg opened this issue Jun 25, 2019 · 0 comments
Open

Functions that do not own types implementing Drop #11

gnzlbg opened this issue Jun 25, 2019 · 0 comments

Comments

@gnzlbg
Copy link

gnzlbg commented Jun 25, 2019

The C setjmp/longjmp APIs deallocate stack allocated objects in function stack frames without calling destructors. Code that uses these two APIs is safe iff when the setjmp is replaced with a catch_unwind and the longjmp is replaced with panic!, no destructors are run between the executing of the panic and after the catch_unwind when panic=unwind.

Sometimes one needs to pass Rust callbacks to C code that uses setjmp, and the Rust callback needs to call C code that uses longjmp: C(setjmp)->Rust->C(longjmp).

The Rust code in the middle needs to prove that no types implement Drop between all execution paths from a longjmp to a setjmp.

One coarse way to prove this would be by statically rejecting all Rust functions that contain types implementing Drop in their stack frames. Those Rust functions might need to call generic code, that might or might not satisfy this property depending on the concrete generic parameters. This ends up requiring generic code to be polymorphic about this property.

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

2 participants