-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Clarify Box<T>
representation and its use in FFI
#62514
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
Changes from all commits
318c5d6
aea9423
812ec6a
ead1159
fe6ddd5
1a26df7
cb1cc11
fafa489
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -63,7 +63,60 @@ | |
//! T` obtained from `Box::<T>::into_raw` may be deallocated using the | ||
//! [`Global`] allocator with `Layout::for_value(&*value)`. | ||
//! | ||
//! So long as `T: Sized`, a `Box<T>` is guaranteed to be represented | ||
//! as a single pointer and is also ABI-compatible with C pointers | ||
//! (i.e. the C type `T*`). This means that if you have extern "C" | ||
//! Rust functions that will be called from C, you can define those | ||
//! Rust functions using `Box<T>` types, and use `T*` as corresponding | ||
//! type on the C side. As an example, consider this C header which | ||
//! declares functions that create and destroy some kind of `Foo` | ||
//! value: | ||
//! | ||
//! ```c | ||
//! /* C header */ | ||
//! | ||
//! /* Returns ownership to the caller */ | ||
//! struct Foo* foo_new(void); | ||
//! | ||
//! /* Takes ownership from the caller; no-op when invoked with NULL */ | ||
//! void foo_delete(struct Foo*); | ||
//! ``` | ||
//! | ||
//! These two functions might be implemented in Rust as follows. Here, the | ||
//! `struct Foo*` type from C is translated to `Box<Foo>`, which captures | ||
//! the ownership constraints. Note also that the nullable argument to | ||
//! `foo_delete` is represented in Rust as `Option<Box<Foo>>`, since `Box<Foo>` | ||
//! cannot be null. | ||
//! | ||
//! ``` | ||
//! #[repr(C)] | ||
//! pub struct Foo; | ||
//! | ||
//! #[no_mangle] | ||
//! pub extern "C" fn foo_new() -> Box<Foo> { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Usually a function like There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @briansmith this is a long-merged PR, so new comments here are bound to get lost... please open an issue if you think this needs to be tracked. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
It's no different than "regular" FFI code where one returns raw pointer and requires the caller to call the corresponding If you open a new issue, please cc me, this is a pattern close to my heart :) |
||
//! Box::new(Foo) | ||
//! } | ||
//! | ||
//! #[no_mangle] | ||
//! pub extern "C" fn foo_delete(_: Option<Box<Foo>>) {} | ||
nikomatsakis marked this conversation as resolved.
Show resolved
Hide resolved
|
||
//! ``` | ||
//! | ||
//! Even though `Box<T>` has the same representation and C ABI as a C pointer, | ||
//! this does not mean that you can convert an arbitrary `T*` into a `Box<T>` | ||
//! and expect things to work. `Box<T>` values will always be fully aligned, | ||
//! non-null pointers. Moreover, the destructor for `Box<T>` will attempt to | ||
//! free the value with the global allocator. In general, the best practice | ||
//! is to only use `Box<T>` for pointers that originated from the global | ||
//! allocator. | ||
//! | ||
//! **Important.** At least at present, you should avoid using | ||
//! `Box<T>` types for functions that are defined in C but invoked | ||
//! from Rust. In those cases, you should directly mirror the C types | ||
//! as closely as possible. Using types like `Box<T>` where the C | ||
//! definition is just using `T*` can lead to undefined behavior, as | ||
//! described in [rust-lang/unsafe-code-guidelines#198][ucg#198]. | ||
//! | ||
//! [ucg#198]: https://github.com/rust-lang/unsafe-code-guidelines/issues/198 | ||
//! [dereferencing]: ../../std/ops/trait.Deref.html | ||
//! [`Box`]: struct.Box.html | ||
//! [`Global`]: ../alloc/struct.Global.html | ||
|
Uh oh!
There was an error while loading. Please reload this page.