commit | 5f5dd649c1ec1eecf642d3c17b5022c1890a3c54 | [log] [tgz] |
---|---|---|
author | Andrew Walbran <qwandor@google.com> | Fri Nov 17 12:48:06 2023 +0000 |
committer | Andrew Walbran <qwandor@google.com> | Fri Nov 17 12:48:06 2023 +0000 |
tree | 78ee8048f5d966e3f2f018f63c2a055f8555dba6 | |
parent | 738d78f6696da049502fc4436a70ca8799e1569e [diff] |
Migrate to cargo_embargo. Bug: 293289578 Test: Ran cargo_embargo, compared Android.bp Change-Id: I2b4e579dd316c4582243fe0343737c3c26619903
Want to help improve zerocopy? Fill out our user survey!
Fast, safe, compile error. Pick two.
Zerocopy makes zero-cost memory manipulation effortless. We write unsafe
so you don't have to.
Zerocopy provides four core marker traits, each of which can be derived (e.g., #[derive(FromZeroes)]
):
FromZeroes
indicates that a sequence of zero bytes represents a valid instance of a typeFromBytes
indicates that a type may safely be converted from an arbitrary byte sequenceAsBytes
indicates that a type may safely be converted to a byte sequenceUnaligned
indicates that a type's alignment requirement is 1Types which implement a subset of these traits can then be converted to/from byte sequences with little to no runtime overhead.
Zerocopy also provides byte-order aware integer types that support these conversions; see the byteorder
module. These types are especially useful for network parsing.
alloc
By default, zerocopy
is no_std
. When the alloc
feature is enabled, the alloc
crate is added as a dependency, and some allocation-related functionality is added.
byteorder
(enabled by default) Adds the byteorder
module and a dependency on the byteorder
crate. The byteorder
module provides byte order-aware equivalents of the multi-byte primitive numerical types. Unlike their primitive equivalents, the types in this module have no alignment requirement and support byte order conversions. This can be useful in handling file formats, network packet layouts, etc which don't provide alignment guarantees and which may use a byte order different from that of the execution platform.
derive
Provides derives for the core marker traits via the zerocopy-derive
crate. These derives are re-exported from zerocopy
, so it is not necessary to depend on zerocopy-derive
directly.
However, you may experience better compile times if you instead directly depend on both zerocopy
and zerocopy-derive
in your Cargo.toml
, since doing so will allow Rust to compile these crates in parallel. To do so, do not enable the derive
feature, and list both dependencies in your Cargo.toml
with the same leading non-zero version number; e.g:
[dependencies] zerocopy = "0.X" zerocopy-derive = "0.X"
simd
When the simd
feature is enabled, FromZeroes
, FromBytes
, and AsBytes
impls are emitted for all stable SIMD types which exist on the target platform. Note that the layout of SIMD types is not yet stabilized, so these impls may be removed in the future if layout changes make them invalid. For more information, see the Unsafe Code Guidelines Reference page on the layout of packed SIMD vectors.
simd-nightly
Enables the simd
feature and adds support for SIMD types which are only available on nightly. Since these types are unstable, support for any type may be removed at any point in the future.
Disclaimer: Zerocopy is not an officially supported Google product.