Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
779: Don't call assume_init on Deferred's Data r=taiki-e a=saethlin This situation can be observed by running `MIRIFLAGS="-Zmiri-check-number-validity" cargo miri test` in `crossbeam/crossbeam-deque`: ``` test is_empty ... error: Undefined Behavior: type validation failed at .value[0]: encountered uninitialized bytes --> /home/ben/crossbeam/crossbeam-epoch/src/deferred.rs:49:27a | 49 | data: data.assume_init(), | ^^^^^^^^^^^^^^^^^^ type validation failed at .value[0]: encountered uninitialized bytes | ``` In the crossbeam-deque test suite, a `Deferred` was created from a `FnOnce` which is smaller than the `Data`. This makes the call to `MaybeUninit::assume_init()` immediate UB (the reference to it created upon call is probably UB too). [The docs for `MaybeUninit::assume_init()`](https://doc.rust-lang.org/stable/core/mem/union.MaybeUninit.html#safety) say this: > It is up to the caller to guarantee that the MaybeUninit<T> really is in an initialized state. Calling this when the content is not yet fully initialized causes immediate undefined behavior. The [type-level documentation](https://doc.rust-lang.org/stable/core/mem/union.MaybeUninit.html#initialization-invariant) contains more information about this initialization invariant. Since `Data` doesn't have a `Drop` impl, we can just leave it in the `MaybeUninit` wrapper. This removes all issues about type validity. Co-authored-by: Ben Kimock <kimockb@gmail.com>
- Loading branch information