Document pointer cast safety in std::path

[udoprog]

Hey,

I'm curious about the unsafe cast in Path.

From what I understand: this works because Path is a single member struct containing only the type it's being reinterpreted as.

My original question on #rust IRC was: Is this always guaranteed to be correct (in Rust) in terms of memory layout?

The discussion seemed to hint at that this is in fact not a guarantee, but that std is in a unique position being developed in concert with the language and any future breakage would be patched when it occurs.

I would love some clarification if this usage is correct or to what degree it is not. I'd also suggest we add clarification around this case with comments or support functions to aid future spelunking into std.

[cramertj]

No, strictly speaking, this is not safe without #[repr(transparent)].

[udoprog]

@cramertj excellent, thank you!

The tracking issue seems to indicate things going slowly. Adding a comment might still be a good idea for now.

Reading the RFC, it mentions at least ARM64 where there might be layout differences. But according to platform support, std shows up as supported as a Tier 2 platform. This implies that at least for now, this pattern in this instance (OsStr) works. Is this correct?

[bluss]

@udoprog That ARM64 issue seems to be related to calling convention, not memory layout, so it's not an issue here.

[dtolnay]

The discussion seemed to hint at that this is in fact not a guarantee, but that std is in a unique position being developed in concert with the language and any future breakage would be patched when it occurs.

This is my understanding as well.

No, strictly speaking, this is not safe without #[repr(transparent)].

I believe it is safe with either repr(transparent) or repr(C), the latter of which is stable. The ref-cast crate is a generalization of this safe cast.