3 releases

0.0.2 Mar 7, 2020
0.0.1 Mar 2, 2020
0.0.0-alpha Mar 1, 2020

#674 in Memory management

Zlib license

535 lines

License:Zlib crates.io docs.rs


Helps add some stability to your metal!

For actual explanations of stuff, see the crate docs


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.


  • unsafe_alloc enables support for Vec, String, and Box.
    • 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.

No runtime deps