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

Require `#[repr(C)]` for `RelativePath` #2

Open
lo48576 opened this Issue Dec 26, 2017 · 2 comments

Comments

Projects
None yet
2 participants
@lo48576
Copy link

lo48576 commented Dec 26, 2017

I heard that the code such as below is unsound (lead to undefined behaviour):

relative-path/src/lib.rs

Lines 271 to 280 in 49d76f3

/// A borrowed, immutable relative path.
pub struct RelativePath {
inner: str,
}
impl RelativePath {
/// Directly wraps a string slice as a `RelativePath` slice.
pub fn new<S: AsRef<str> + ?Sized>(s: &S) -> &RelativePath {
unsafe { mem::transmute(s.as_ref()) }
}

RelativePath type should have #[repr(C)] (stable) or #[repr(transparent)] (unstable) to be safe.

This is because Rust doesn't guarantee that str and RelativePath have the same internal representations (and it will be guaranteed by #[repr(C)]).

For detail:

@udoprog

This comment has been minimized.

Copy link
Owner

udoprog commented Dec 26, 2017

Also: rust-lang/rust#45910

Yeah, I'm keeping an eye on the stabilization for #[repr(transparent)] for this. I guess we could consider using #[repr(C)] until then.

@udoprog udoprog added the bug label Dec 26, 2017

@udoprog

This comment has been minimized.

Copy link
Owner

udoprog commented Aug 28, 2018

🎉 #[repr(transparent)] is now in stable (1.28)!

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