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
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.
The text was updated successfully, but these errors were encountered:
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 (rust-lang/miri#845)
Recent miri fails in
inline_array::test::sufficiently_alignment1
, complaining that the length field is uninitialized. I think the issue is that theInlineArray
gets moved between writing the length and reading it. In this test, the data of theInlineArray
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.The text was updated successfully, but these errors were encountered: