Messages in this thread | | | Date | Fri, 31 Mar 2023 01:20:06 +0100 | From | Gary Guo <> | Subject | Re: [PATCH v3 09/13] rust: init: add `Zeroable` trait and `init::zeroed` function |
| |
On Fri, 31 Mar 2023 00:40:34 +0200 Alice Ryhl <alice@ryhl.io> wrote:
> On 3/30/23 00:33, y86-dev@protonmail.com wrote: > > From: Benno Lossin <y86-dev@protonmail.com> > > > > Add the `Zeroable` trait which marks types that can be initialized by > > writing `0x00` to every byte of the type. Also add the `init::zeroed` > > function that creates an initializer for a `Zeroable` type that writes > > `0x00` to every byte. > > > > Signed-off-by: Benno Lossin <y86-dev@protonmail.com> > > --- > > +// SAFETY: `null` pointer is valid. > > +unsafe impl<T: ?Sized> Zeroable for *mut T {} > > +unsafe impl<T: ?Sized> Zeroable for *const T {} > > Actually, I just realized that this is not ok for unsized types. When T > is unsized, the raw pointer is a fat pointer with a vtable, and the > vtable part is not necessarily zeroable. > > However, it would be ok to do it for `*const [T]` since the fat part of > the pointer is just the length in this case, and a length of zero is fine. > > See more here: > https://github.com/Lokathor/bytemuck/blob/8391afa876ba2e99dffb0c991cc7fa775287d106/src/zeroable.rs#L56-L65
Good catch. vtable completely slipped my mind when I am reviewing this code.
Vtable is not *not necessary zeroable*, but actually never zeroable. Although currently not yet formally specified, the compiler has always assumed vtable part of fat pointers to be non-null, well aligned and dereferenceable.
Best, Gary
| |