Guarantee that it is sound to observe the bytes of None::<P> where P is a pointer type subject to NPO

[joshlf]

In #115333, we added a guarantee that transmuting from [0u8; N] to Option<P> is sound where P is a pointer type subject to the null pointer optimization (NPO). It would be useful to be able to guarantee the inverse - that if all of the bytes of P are initialized, then all of the bytes of None::<P> (and thus all of the bytes of any Option<P>) are initialized. For example, this would allow zerocopy to support safe transmutation from Option<P> to [u8; N] (google/zerocopy#596).

I'm opening this issue first rather than a PR so there's an opportunity to discuss whether this is something we want, how it would be best to document it, etc.

[RalfJung]

Cc @rust-lang/opsem

For thin pointer this seems perfectly fine, I am just not sure where to best document it.

I think for wide pointers, this is actually not true today (and seems unlikely to ever be true) -- the discriminant will be stored in one of the two "fields" of the pointer, which means that for None the other field is padding.

[joshlf]

Sounds good. Put up a PR to guarantee this for thin pointers: #137323

[RalfJung]

In #115333, we added a guarantee that transmuting from [u8; N] to Option<P> is sound where P is a pointer type subject to the null pointer optimization (NPO).

No that's not what that PR did? It just talks specifically about transmuting [0u8; N], not arbitrary arrays of that type.

And similarly, looking at what you did in the new PR, it doesn't seem to match the issue description. The PR only guarantees that None::<P> can be transmuted to a u8 array and will yield a bunch of 0u8; it doesn't talk about e.g. transmuting Some(Box::new(i32)). That would be a ptr-to-int transmute so it is anyway tangled up in rust-lang/unsafe-code-guidelines#547.

[joshlf]

In #115333, we added a guarantee that transmuting from [u8; N] to Option<P> is sound where P is a pointer type subject to the null pointer optimization (NPO).

No that's not what that PR did? It just talks specifically about transmuting [0u8; N], not arbitrary arrays of that type.

Good point; updated the issue text.

And similarly, looking at what you did in the new PR, it doesn't seem to match the issue description. The PR only guarantees that None::<P> can be transmuted to a u8 array and will yield a bunch of 0u8; it doesn't talk about e.g. transmuting Some(Box::new(i32)). That would be a ptr-to-int transmute so it is anyway tangled up in rust-lang/unsafe-code-guidelines#547.

Yeah, I realized the ptr-to-int issue and decided to stick with the more limited (and hopefully less controversial) None case.