New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document pointer cast safety in std::path #45910

Open
udoprog opened this Issue Nov 10, 2017 · 4 comments

Comments

Projects
None yet
5 participants
@udoprog
Copy link
Contributor

udoprog commented Nov 10, 2017

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

This comment has been minimized.

Copy link
Member

cramertj commented Nov 10, 2017

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

@udoprog

This comment has been minimized.

Copy link
Contributor

udoprog commented Nov 10, 2017

@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?

@Mark-Simulacrum Mark-Simulacrum changed the title Use of unsafe cast in std::path Document pointer cast safety in std::path Nov 11, 2017

@bluss

This comment has been minimized.

Copy link
Contributor

bluss commented Nov 12, 2017

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

@dtolnay

This comment has been minimized.

Copy link
Member

dtolnay commented Nov 14, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment