Document in libstd where we rely on unspecified layout details

[RalfJung]

In rust-lang/rust#58582, the issue came up that libstd does things we do not permit user code to do: it relies on unspecified details of data type layout. from_raw_parts is a prime example of such code.

It'd be great if we could clearly mark every occurrence of this with comments in the standard library. This is of course directly related to the previous discussion topic where we determined what we do and do not guarantee about data type layout -- the more we guarantee, the fewer such comments are needed.

We can use this issue to collect places that do rely on unspecified layout, and then hopefully someone can prepare a PR to add appropriate comments.

[gnzlbg]

The ffi::CStr type would be another example. Its layout is "unspecified" (it is not just a *const c_char, yet). That is, one can't use ffi::CStr on C FFI.

[RalfJung]

I don't think that is what I meant. There are no transmute there that assume fields have particular offsets, or such things, right?

I am asking for code making assumptions about how the compiler performs layout. Stuff like this, which makes assumptions about how slices are laid out (which we haven't guaranteed, AFAIK):

pub unsafe fn from_raw_parts<'a, T>(data: *const T, len: usize) -> &'a [T] {
    Repr { raw: FatPtr { data, len } }.rust
}

[gnzlbg]

My point was that the CStr type defines its layout as unspecified but the standard library makes use of its knowledge of it being specified in a certain way, but I recognize that this is not different from the standard library types having private fields that user code cannot know about, and making use of that knowledge internally.

Maybe you can look for places where the standard library might assume niche optimizations that are not guaranteed, like, e.g., Result<(), NonZero<c_int>> having the same layout as c_int or similar.

[gnzlbg]

Or MaybeUninit assuming that () and T are at the same offset, etc.

[RalfJung]

the CStr type defines its layout as unspecified

That's exactly what I was not asking for. :)
I am looking for things the compiler/language doesn't specify, as opposed to things library abstractions want to leave opaque. Those are entirely different questions.

Maybe you can look for places where the standard library might assume niche optimizations that are not guaranteed, like, e.g., Result<(), NonZero<c_int>> having the same layout as c_int or similar.

Yes! That's what I am asking for. Where does libstd do that?

Or MaybeUninit assuming that () and T are at the same offset, etc.

Yes! We should make it repr(C) repr(transparent) once that's a thing.

[RalfJung]

See rust-lang/rust#62522 for another case of libstd relying on "magic".

[RalfJung]

Cc rust-lang/rust#49456

[RalfJung]

Here's a list by 0b_0101_001_1010 of a bunch of place where the standard library or compiler are making layout assumptions. They should be fixed via repr annotations or have appropriate comments added.

[JakobDegen]

Closing as not having been a fruitful issue in 4 years and not being clearly opsem territory