Skip to content
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

Tracking issue for `vec_into_raw_parts` #65816

Open
shepmaster opened this issue Oct 25, 2019 · 3 comments
Open

Tracking issue for `vec_into_raw_parts` #65816

shepmaster opened this issue Oct 25, 2019 · 3 comments

Comments

@shepmaster
Copy link
Member

@shepmaster shepmaster commented Oct 25, 2019

#65705 adds:

impl String {
    pub fn into_raw_parts(self) -> (*mut u8, usize, usize) {…}
}
impl<T> Vec<T> {
    pub fn into_raw_parts(self) -> (*mut T, usize, usize) {…}
}

Things to evaluate before stabilization

@SimonSapin

This comment has been minimized.

Copy link
Contributor

@SimonSapin SimonSapin commented Oct 25, 2019

Should the returned pointer be a NonNull instead? Box::raw doesn’t do that because it was stabilized before NonNull was.

Centril added a commit to Centril/rust that referenced this issue Oct 25, 2019
Add {String,Vec}::into_raw_parts

Aspects to address:

- [x] Create a tracking issue
  - rust-lang#65816
JohnTitor added a commit to JohnTitor/rust that referenced this issue Oct 25, 2019
Add {String,Vec}::into_raw_parts

Aspects to address:

- [x] Create a tracking issue
  - rust-lang#65816
@shepmaster

This comment has been minimized.

Copy link
Member Author

@shepmaster shepmaster commented Oct 25, 2019

Should these functions be associated functions like Box::into_raw? The Box case is required because we want to avoid colliding with methods exposed by Deref / DerefMut. This isn't a concern for String or Vec<T>, but it may be nice to be consistent across this family of similar functions.

@matklad

This comment has been minimized.

Copy link
Member

@matklad matklad commented Oct 28, 2019

Here's an example where this might have helped with avoiding UB: confio/go-rust-demo#1 (comment). There, the vector was destructed manually and mem::forgetted, however, len was used in place of both length and capacity. If Vec::from_raw_parts was a thing, it might have prevented this issue, as, with cap on your hands, you are more likely to do the right thing with it.

danielhenrymantilla added a commit to danielhenrymantilla/rust that referenced this issue Nov 24, 2019
Use `Vec::into_raw_parts` instead of a manual implementation of
`Vec::transmute`.

If `Vec::into_raw_parts` uses `NonNull` instead, then the code here
will need to be adjusted to take it into account (issue rust-lang#65816)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.