|
84 | 84 | //!
|
85 | 85 | //! # Cargo Features
|
86 | 86 | //!
|
87 |
| -//! - **`alloc`** |
| 87 | +//! - **`alloc`** |
88 | 88 | //! By default, `zerocopy` is `no_std`. When the `alloc` feature is enabled,
|
89 | 89 | //! the `alloc` crate is added as a dependency, and some allocation-related
|
90 | 90 | //! functionality is added.
|
|
94 | 94 | //! `std` crate is added as a dependency (ie, `no_std` is disabled), and
|
95 | 95 | //! support for some `std` types is added. `std` implies `alloc`.
|
96 | 96 | //!
|
97 |
| -//! - **`derive`** |
| 97 | +//! - **`derive`** |
98 | 98 | //! Provides derives for the core marker traits via the `zerocopy-derive`
|
99 | 99 | //! crate. These derives are re-exported from `zerocopy`, so it is not
|
100 |
| -//! necessary to depend on `zerocopy-derive` directly. |
| 100 | +//! necessary to depend on `zerocopy-derive` directly. |
101 | 101 | //!
|
102 | 102 | //! However, you may experience better compile times if you instead directly
|
103 | 103 | //! depend on both `zerocopy` and `zerocopy-derive` in your `Cargo.toml`,
|
|
111 | 111 | //! zerocopy-derive = "0.X"
|
112 | 112 | //! ```
|
113 | 113 | //!
|
114 |
| -//! - **`simd`** |
| 114 | +//! - **`simd`** |
115 | 115 | //! When the `simd` feature is enabled, `FromZeros`, `FromBytes`, and
|
116 | 116 | //! `IntoBytes` impls are emitted for all stable SIMD types which exist on the
|
117 | 117 | //! target platform. Note that the layout of SIMD types is not yet stabilized,
|
118 | 118 | //! so these impls may be removed in the future if layout changes make them
|
119 | 119 | //! invalid. For more information, see the Unsafe Code Guidelines Reference
|
120 | 120 | //! page on the [layout of packed SIMD vectors][simd-layout].
|
121 | 121 | //!
|
122 |
| -//! - **`simd-nightly`** |
| 122 | +//! - **`simd-nightly`** |
123 | 123 | //! Enables the `simd` feature and adds support for SIMD types which are only
|
124 | 124 | //! available on nightly. Since these types are unstable, support for any type
|
125 | 125 | //! may be removed at any point in the future.
|
|
131 | 131 | //! Zerocopy is expressly designed for use in security-critical contexts. We
|
132 | 132 | //! strive to ensure that that zerocopy code is sound under Rust's current
|
133 | 133 | //! memory model, and *any future memory model*. We ensure this by:
|
134 |
| -//! - **...not 'guessing' about Rust's semantics.** |
| 134 | +//! - **...not 'guessing' about Rust's semantics.** |
135 | 135 | //! We annotate `unsafe` code with a precise rationale for its soundness that
|
136 | 136 | //! cites a relevant section of Rust's official documentation. When Rust's
|
137 | 137 | //! documented semantics are unclear, we work with the Rust Operational
|
138 | 138 | //! Semantics Team to clarify Rust's documentation.
|
139 |
| -//! - **...rigorously testing our implementation.** |
| 139 | +//! - **...rigorously testing our implementation.** |
140 | 140 | //! We run tests using [Miri], ensuring that zerocopy is sound across a wide
|
141 | 141 | //! array of supported target platforms of varying endianness and pointer
|
142 | 142 | //! width, and across both current and experimental memory models of Rust.
|
143 |
| -//! - **...formally proving the correctness of our implementation.** |
| 143 | +//! - **...formally proving the correctness of our implementation.** |
144 | 144 | //! We apply formal verification tools like [Kani][kani] to prove zerocopy's
|
145 | 145 | //! correctness.
|
146 | 146 | //!
|
@@ -1953,6 +1953,15 @@ fn swap<T, U>((t, u): (T, U)) -> (U, T) {
|
1953 | 1953 | /// overhead. This is useful whenever memory is known to be in a zeroed state,
|
1954 | 1954 | /// such memory returned from some allocation routines.
|
1955 | 1955 | ///
|
| 1956 | +/// # Warning: Padding bytes |
| 1957 | +/// |
| 1958 | +/// Note that, when an object is moved or copied, only the non-padding bytes of |
| 1959 | +/// that object are guaranteed to be preserved. It is unsound to assume that |
| 1960 | +/// values written to padding bytes are preserved after a move or copy. For more |
| 1961 | +/// details, see the [`FromBytes` docs][frombytes-warning-padding-bytes]. |
| 1962 | +/// |
| 1963 | +/// [frombytes-warning-padding-bytes]: FromBytes#warning-padding-bytes |
| 1964 | +/// |
1956 | 1965 | /// # Implementation
|
1957 | 1966 | ///
|
1958 | 1967 | /// **Do not implement this trait yourself!** Instead, use
|
@@ -2431,6 +2440,34 @@ pub use zerocopy_derive::FromBytes;
|
2431 | 2440 | /// can be viewed as any `FromBytes` type with no runtime overhead. This is
|
2432 | 2441 | /// useful for efficiently parsing bytes as structured data.
|
2433 | 2442 | ///
|
| 2443 | +/// # Warning: Padding bytes |
| 2444 | +/// |
| 2445 | +/// Note that, when an object is moved or copied, only the non-padding bytes of |
| 2446 | +/// that object are guaranteed to be preserved. It is unsound to assume that |
| 2447 | +/// values written to padding bytes are preserved after a move or copy. For |
| 2448 | +/// example, the following is unsound: |
| 2449 | +/// |
| 2450 | +/// ```rust,no_run |
| 2451 | +/// use core::mem::{size_of, transmute}; |
| 2452 | +/// use zerocopy::FromZeros; |
| 2453 | +/// # use zerocopy_derive::*; |
| 2454 | +/// |
| 2455 | +/// // Assume `Foo` is a type with padding bytes. |
| 2456 | +/// #[derive(FromZeros, Default)] |
| 2457 | +/// struct Foo { |
| 2458 | +/// # /* |
| 2459 | +/// ... |
| 2460 | +/// # */ |
| 2461 | +/// } |
| 2462 | +/// |
| 2463 | +/// let mut foo: Foo = Foo::default(); |
| 2464 | +/// FromZeros::zero(&mut foo); |
| 2465 | +/// // UNSOUND: Although `FromZeros::zero` writes zeros to all bytes of `foo`, |
| 2466 | +/// // those writes are not guaranteed to be preserved in padding bytes when |
| 2467 | +/// // `foo` is moved, so this may expose padding bytes as `u8`s. |
| 2468 | +/// let foo_bytes: [u8; size_of::<Foo>()] = unsafe { transmute(foo) }; |
| 2469 | +/// ``` |
| 2470 | +/// |
2434 | 2471 | /// # Implementation
|
2435 | 2472 | ///
|
2436 | 2473 | /// **Do not implement this trait yourself!** Instead, use
|
|
0 commit comments