You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit b796035
Browse filesBrowse the repository at this point in the historyBrowse files
fn unaligned_lvl_slice: Safely encapsulate "unaligned" slices of lvl: &[[u8; 4]], as previous accesses were UB (#731)
See:
* #728 (comment)
* #728 (comment)
The current "unaligned" access of `lvl`, added in #726, and a proposed
change in #728, [are UB according to
`miri`](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=80849f822a890cabd324b3b898b291b8),
as they cast `&[u8; 3]` and `&u8` to `&[u8; 4]`, which is an out of
bounds read of a borrow. This `fn unaligned_lvl_slice` helper `fn` fixes
it and passes `miri` by transmuting (through `.align_to`) to a `&[u8]`,
doing the slice, and then doing a checked cast back to `[u8; 4]`. It
also does correct bounds checking, as the previous ways were off by one
in their bounds checking, as they didn't consider the read of the
unaligned part into the next `[u8; 4]`. Doing it this way also optimizes
just as well as the previous methods.
We could also use a dependency like `zerocopy` to encapsulate the
`unsafe` `.align_to`, but as long as these kinds of "unaligned" array
reads are a one-off, doing it inline here seems better.
Update: Switched to using unstable `fn`s from `std` that make things
fully safe and correct, copied into our codebase for stability.
I already figured out how to fix the UB in reviewing #728, so I just
went ahead and made the fix independently.
0 commit comments