7 ms·
Yes, this is the case that I ran into as well. You have to zero memory before reading and/or have some crazy combination of tracking what’s uninitialized capaci
by vgatherps 1y ago
Yes, this is the case that I ran into as well. You have to zero memory before reading and/or have some crazy combination of tracking what’s uninitialized capacity or initialized len, I think the rust stdlib write trait for &mut Vec got butchered over this concern.
It’s strictly more complicated and slower than the obvious thing to do and only exists to satisfy the abstract machine.
- Arnavion 1y agoNo. The correct way to write that code is to use .spare_capacity_mut() to get a &mut [MaybeUninit<T>], then write your Ts into that using .write_copy_of_slice(), then .set_len(). And that will not be any slower (though obviously more complicated) than the original incorrect code.
- vgatherps 1y agoOh this is very nice, I think it was stabilized since I wrote said code.
- nemothekid 1y agowrite_copy_of_slice doesn't look to be stable. I'll mess around with godbolt, but my hope that whatever incantation is used compiles down to a memcpy
- Arnavion 1y agoAs I wrote in https://news.ycombinator.com/item?id=44048391 https://news.ycombinator.com/item?id=44048391 , you have to get used to copying the libstd impl when working with MaybeUninit. For my code I put a "TODO(rustup)" comment on such copies, to remind myself to revisit them every time I update the Rust version in toolchain.toml
- nemothekid 1y agoIn other words the """safe""" stable code looks like this: let mut data = Vec::with_capacity(sz); let mut dst_uninit = data.spare_capacity_mut(); let uninit_src: &[MaybeUninit<T>] = unsafe { transmute(buf) }; dst_uninit.copy_from_slice(uninit_src); unsafe { data.set_len(sz) };
- Arnavion 1y agoThat's correct.