search

jneem / imbl-sized-chunks

Efficient sized chunk datatypes for immutable.rs
Mozilla Public License 2.0
0 stars 3 forks source link

undefined behavior with large alignments #9

Open jneem opened 1 week ago

jneem commented 1 week ago

Recent miri fails in inline_array::test::sufficiently_alignment1, complaining that the length field is uninitialized. I think the issue is that the InlineArray gets moved between writing the length and reading it. In this test, the data of the InlineArray is a [BigAlign; 2], most of which is padding. So when it gets moved, I guess the length becomes uninitialized again because it's mostly overlapping padding bytes.

CraftSpider commented 1 week ago

I looked into this a bit actually - as far as I can tell, what you say is correct. Unfortunately, there's not a good way around this currently. There is no type that allows what is needed here, what's needed is something like const_generic_exprs to allow making a [u8; size_of::<T>()] union. Alternatively, it's possible to require T either have no padding via unsafe trait (like bytemuck::NoUninit), or similarly have an unsafe trait with a Storage assoc type that must be the same size and align as T but with no padding (this is a bit annoying to implement).

At least, these were the ideas people came up with in the Rust community discord when talking about this problem.

The failure is new because, until recently, Miri didn't correctly set padding to uninit on moves (https://github.com/rust-lang/miri/issues/845)

jneem commented 1 week ago

Got it, thanks for the pointers. I guess we just live with the UB for now...