3 releases
0.0.2 | Mar 7, 2020 |
---|---|
0.0.1 | Mar 2, 2020 |
0.0.0-alpha | Mar 1, 2020 |
#703 in Memory management
34KB
535 lines
chromium
Helps add some stability to your metal!
For actual explanations of stuff, see the crate docs
lib.rs
:
Chromium helps add some stability to your metal.
Specifically, this crate lets you turn select repr(Rust)
types into a
repr(C)
struct that holds all the data necessary to safely reconstruct the
original repr(Rust)
form.
This is primarily of use for sending data from Rust code on one side of a C ABI "FFI" call to other Rust code on the far side of that FFI call. Even if the Rust form of the data changes between compiler versions, because the C ABI is stable each side will be able to turn the information back into whatever it locally needs.
You could of course also use this to communicate with non-Rust code if you need to.
The types here provide fairly minimal functionality beyond just turning
themselves back into their repr(Rust)
forms. A few basics like Debug
and
Deref
and so on are provided as appropriate, but for any serious usage
you're expected to just change the value back into the Rust form and use the
"real" form of the data.
Features
unsafe_alloc
enables support forVec
,String
, andBox
.- Note that in this case you must not transfer allocations between two different global allocators.
- As of 2020-03-06 it happens to be the case that the default global allocators for Windows / Mac / Linux are process wide allocators. If you change the global allocator things can break. If the rust standard library changes their global allocator things can break.
- This is a brittle feature, not to be used lightly. That's why it says "unsafe" right in the feature name.