Documenting more layout guarantees

mcy · July 16, 2021, 6:34pm

@joshlf and I were chatting about adding more standard types to zerocopy. There's a few that are contentious, and it might be worth documenting this somewhere:

Is it safe to transmute fn(), &T, &mut T, Box<T>, Arc<T>, Rc<T>, and Option<_> of each, into usize? This question applies for both T: Sized and T = [U].
Is it safe to transmute uX into Option<NonZeroX> and back?
Does ManuallyDrop<T> have the same niches as T, such that if an enum with a T in it has no padding due to niche-filling, replacing it with ManuallyDrop<T> doesn't, either? E.g. is Option<ManuallyDrop<&T>> a single word or two?
If a type is declared repr(transparent) in std, is that a stability promise? I assume so but I can't find a citation for that.

Thanks!

jhpratt · July 16, 2021, 7:18pm

For the various pointer types, check out rust-lang/unsafe-code-guidelines#286. It's not yet a settled issue (except at compile time, which will be landing soon).
For transmuting uX into Option<NonZeroX> and vice versa, I believe that would be safe given the layout guarantees of Option<NonZeroX> — zero is always None.
Given ManuallyDrop is #[repr(transparent)], this is in fact the situation. This is stated in the documentation right at the top.
#[repr(transparent)] is absolutely a stability promise.

mcy · July 16, 2021, 7:26pm

Thank you! I was not aware that we were considering doing this with ptr2int. I was undert the impression that ptr -> int -> ptr produced a fresh pointer of unspecified provenance, similar to materializing a pointer into e.g. hardware registers out of the aether.

For now, I think we can assume that none of the pointer types can be directly transmuted (i.e., without going through ptr2int or int2ptr at the LLVM level).

For the others, thanks. I was pretty certain all those were correct but Josh was a bit nervous about it. =)

steffahn · July 16, 2021, 8:50pm

Even though it's true for ManuallyDrop, you can't rely on this behavior based on repr(transparent) alone. UnsafeCell and MaybeUninit are repr(transparent), too, and neither preserves niches.

SkiFire13 · July 16, 2021, 10:18pm

The documentation of each NonZeroX already says they have the same layout.

TIL UnsafeCell doesn't preserve niches. It makes sense for MaybeUninit<T> since it isn't a direct wrapper around T, it's an union, but what is the reason for UnsafeCell?

quinedot · July 16, 2021, 10:31pm

Here's the writeup which links to some related rust and UCG issues that contain further discussion.

InfernoDeity · July 16, 2021, 10:35pm

fn() is fun. It may or may not be a hard error depending on the platform. For T: Sized, this is well-formed, but has a few issues that could make it UB (What about: Pointer-to-integer transmutes? · Issue #286 · rust-lang/unsafe-code-guidelines · GitHub). For T = [U] this transmute will be a compile-time error since they aren't the same size.

CAD97 · July 16, 2021, 10:45pm

It's interesting that the intent discussed there doesn't match rustc's current behavior, which avoids niche optimization for UnsafeCell and RefCell, but still does it for Cell, RwLock, and Mutex.

Though I suppose for RwLock/Mutex it might be niching a different part of the structure, e.g. the Box for the system impl. So that could match the discussed plan + reënabling niching for Cell.

scottmcm · July 16, 2021, 11:15pm

Look in the docs for std to see what's guaranteed. If it's not specifically mentioned in the docs, it's not guaranteed.

For example, this section for Option: https://doc.rust-lang.org/std/option/index.html#representation

(If you think there's something that should be guaranteed but isn't documented, then send a PR for the docs and the libs team will consider it.)

RustyYato · July 16, 2021, 11:15pm

Mutex and RwLock both contain a Box on some platforms, which does have a niche

joshlf · July 16, 2021, 11:16pm

What about transmuting into two usizes side-by-side (we're not actually asking about std::mem::transmute, but rather asking about whether the layouts are well-defined and don't contain any padding/poison bytes)

InfernoDeity · July 16, 2021, 11:22pm

For transmute, that would work, though it would implicate the same issue I mentioned for the thin pointers. However, if it's just layout, then I believe yes, &[T] has the size of 2 usizes, though it's unspecified which is what. All thin pointers, though (T: Sized), are guaranteed to have the same size as usize, and (based on this informal discussion) may not have padding bits or bytes.

quinedot · July 17, 2021, 12:09am

I don't have an explanation but that does indeed seem to be the case, and as far as I can tell the current behavior has been the behavior since the PR landed in 1.43. An exception for Cell did not seem to be intended based on the comments in the PR to my reading. Perhaps some follow-up is in order.

SkiFire13 · July 17, 2021, 8:26am

Even more interesting, looks like the current behaviour of a type that contains an UnsafeCell is to allow niche optimizations only if it doesn't contains something else before the UnsafeCell, and that something is not a ZST. Rust Playground That's weird...

This comment seems to imply it was kinda intended.

quinedot · July 17, 2021, 8:34am

I saw that comment too, but took it to mean it was a future possibility and not the current plan. Cell is still just a repr(transparent) UnsafeCell.

I'll post a comment in one of the issues asking for clarification when I get a minute to write it up, if no one else has.

RalfJung · July 17, 2021, 12:27pm

I am pretty sure Cell exposing the niche is a bug... at least I don't remember that being part of the deal (though my memory for such things is bad), and now I wonder about the soundness of that.^^ Could you open an issue?

As was already mentioned, be careful with ptr-to-int transmutes. There are some sleeping daemons here, and it might well be that LLVM has to declare such transmutes to return poison or else risk losing some crucial optimizations (or else have serious soundness bugs).

github.com/rust-lang/unsafe-code-guidelines

What about: Pointer-to-integer transmutes?

opened 05:32PM - 07 Jun 21 UTC

RalfJung

C-open-question A-provenance

Transmuting pointers to integers (i.e., not going through the regular cast) is a… problem. This is demonstrated by the following silly example: ```rust fn example(ptr: *const i32, cmp: usize) -> usize { unsafe { let mut storage: usize = 0; *(&mut storage as *mut _ as *mut *const i32) = ptr; // write at ptr type let val = storage; // read at int type (0) storage = val; // redundant write back (1) external_function(&storage); // just making sure the value in `storage` can be observed if val == cmp { return cmp; // could exploit integer equivalence (2) } return 0; } } ``` Imagine executing this code on the Abstract Machine, taking into account that pointers have provenance, i.e., a ptr-to-int conversion loses information. Now what happens at point (0)? Here we read the data stored in `storage` at type `usize`. That data however is the ptr `ptr`, i.e., it has provenance. What should happen with that provenance at (0)? 1. We could drop the provenance. That would basically mean that the load of `storage` acts like an implicit ptr-to-int cast. The problem with this approach is that we cannot remove the redundant write at (1): the value in `val` is *different* from what is stored in `storage`, since `val` has no provenance but the `ptr` stored in `storage` does! This is basically another version of https://bugs.llvm.org/show_bug.cgi?id=34548: ptr-to-int casts are *not* NOPs, and a ptr-int-ptr roundtrip cannot be optimized away. If a load, like at (0), can perform a ptr-to-int cast, now the same concerns apply here. 2. We could preserve the provenance. Then, however, we end up with `val` having type `usize` and *also* having provenance, which is a big problem: the compiler might decide, at program point (2), to `return val` instead of `return cmp` (based on the fact that `val == cmp`), but if `val` could have provenance then this transformation is wrong! This is basically the isue at the heart of [my blog post on provenance](https://www.ralfj.de/blog/2020/12/14/provenance.html): `==` ignores provenance, so just because two values are equal according to `==` does not mean they can be used interchangeably in all circumstances. 3. What other option is there? Well, we might make the load return `poison` -- effectively declaring ptr-to-int transmutes as UB. The last option is what is being [proposed to LLVM](https://lists.llvm.org/pipermail/llvm-dev/2021-June/150883.html), along with a new "byte" type such that loading at type `bN` would preserve provenance, but loading at type `iN` would turn bytes with provenance into `poison`. On the flipside, no arithmetic or logical operations are possible on `bN`; that type represents "opaque bytes" with the only possible operations being load and store (and explicit casts to remove any provenance that might exist). This leads to a consistent model in which both redundant store elimination and GVN substitution on integer types (the optimizations mentioned above) are possible. I don't know any other way to resolve the [contradiction that otherwise arises from doing both of these optimizations](https://github.com/rust-lang/unsafe-code-guidelines/issues/286#issuecomment-860189806). However, the LLVM discussion is still in its early stages, and there were already a lot of responses that I have not read in detail yet. *If* this ends up being accepted, we on the Rust side will have to figure out if and how we can make use of the new "byte" type and its explicit casts (to pointers or integers). This thread is about discussing how we need to restrict ptr-to-int transmutes when pointers have provenance but integers do not. See https://github.com/rust-lang/unsafe-code-guidelines/issues/287 for a discussion with the goal of avoiding provenance in the first place.

What is that based on? Usually I'd think only things visible in rustdoc are promised, everything else is an implementation detail gleaned by inspecting the source code.

RustyYato · July 17, 2021, 1:13pm

repr(transparent) does show up in the docs, if you expand out the type definition at the top. Just like all other #[attributes]

RalfJung · July 17, 2021, 1:46pm

Hm, that's fair...

Still I was a bit surprised by how definitely that statement was made.^^ That means adding a repr to a pub type should essentially require FCP, which doesn't match my recollection of how we usually do this (e.g., MaybeUninit is repr(transparent) but on a union that actually means much less than it does otherwise and it was done just to not kill performance...).

steffahn · July 17, 2021, 6:02pm

While the repr shows up, the private field(s) are not shown, so the repr(transparent) in the docs don’t really tell you anything.

quinedot · July 21, 2021, 6:07am

github.com/rust-lang/rust

Niches of `Cell` and others still not hidden

opened 06:06AM - 21 Jul 21 UTC

QuineDot

C-bug

Original conversation can be found in [this IRLO thread](https://internals.rust-…lang.org/t/documenting-more-layout-guarantees/15032/), including a request from @RalfJung to file a bug report. [PR 68491](https://github.com/rust-lang/rust/pull/68491) was accepted to hide niches of types that are in an `UnsafeCell`. However, experiments show that niches are still exposed within `Cell`, `Mutex`, and others. [Consider this code](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=379bcc49bb7c097d3055426e3e2c53e6), adapted from a playground by @SkiFire13. It currently runs on the playground without panicking and [optimizes down to a `ret` in the Godbolt explorer](https://rust.godbolt.org/z/cM9W1f335). ```rust assert_eq!( 8, mem::size_of::< UnsafeCell<&()> >()); // 8 assert_eq!(16, mem::size_of::<Option<UnsafeCell<&()>>>()); // 16 (✗ niche opt) assert_eq!( 8, mem::size_of::< Cell<&()> >()); // 8 assert_eq!( 8, mem::size_of::<Option< Cell<&()>>>()); // 8 (✓ niche opt) assert_eq!(16, mem::size_of::< RefCell<&()> >()); // 16 assert_eq!(24, mem::size_of::<Option< RefCell<&()>>>()); // 24 (✗ niche opt) assert_eq!(24, mem::size_of::< RwLock<&()> >()); // 24 assert_eq!(24, mem::size_of::<Option< RwLock<&()>>>()); // 24 (✓ niche opt) assert_eq!(24, mem::size_of::< Mutex<&()> >()); // 24 assert_eq!(24, mem::size_of::<Option< Mutex<&()>>>()); // 24 (✓ niche opt) ``` I would have expected `Option<Cell<&()>>` to not exhibit the niche-exploiting size optimization. The `RwLock` and `Mutex` cases may or may not be problematic, depending on their platform-specific implementations. But `Cell` in particular is a `#[repr(transparent)]` wrapper around `UnsafeCell`. [Here is another playground by @SkiFire13](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=cb794479d139acda2e3a867dafa1ac90) from which [they observed](https://internals.rust-lang.org/t/documenting-more-layout-guarantees/15032/13): > Even more interesting, looks like the current behaviour of a type that contains an `UnsafeCell` is to allow niche optimizations only if it doesn't contains something else before the `UnsafeCell`, and that something is not a ZST. This indicates that the behavior is not `Cell`-specific. And although there has been some discussion about revealing the niches for `Cell` in particular, the discussion in the PR and in [this hackmd](https://hackmd.io/7rk-0h8WTqKQgaWB6aaeaw) seem to indicate that the niches being exploited is not intentional, even for `Cell`. [The behavior can be observed back until Rust 1.43](https://rust.godbolt.org/z/4h55adY5o) when the PR landed. ### Meta Current playground (all versions) and Godbolt on all versions I tried from 1.43 forward.

Topic		Replies	Views
[Pre-RFC v2] Safe Transmute	32	6110	April 6, 2020
Safe conversions for DSTs	20	1996	March 25, 2019
Safe transmute for transparent struct language design	15	889	March 27, 2024
Is synthesizing zero sized values safe?	32	2419	March 25, 2020
[Pre-RFC]: Safe Transmute language design	57	5189	March 4, 2020

Documenting more layout guarantees

Related topics