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

Clarify guarantees for Vec and String allocation #65801

Open
SimonSapin opened this issue Oct 25, 2019 · 1 comment
Open

Clarify guarantees for Vec and String allocation #65801

SimonSapin opened this issue Oct 25, 2019 · 1 comment
Labels
A-allocators Area: Custom and system allocators A-collections Area: `std::collection` C-enhancement Category: An issue proposing an enhancement or a PR with one. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@SimonSapin
Copy link
Contributor

Similar to what #58183 did for Box, I think we should document a guarantee that Vec<T> and String are allocated through the standard library’s global allocator.

Namely:

  • It is valid (under some conditions) to pass a pointer allocated with std::alloc::Global (or corresponding free functions in std::alloc) to Vec::from_raw_parts.

  • It is valid (under some conditions) to deallocate or reallocate with std::alloc::Global (or corresponding free functions in std::alloc) a pointer from Vec::into_raw_parts (or from ManuallyDrop + Vec::as_mut_ptr).

Conditions include using the appropriate std::alloc::Layout, properly transferring ownership, etc.

Perhaps the documented guarantees should also extend to using NonNull<T>::dangling for zero-size allocations. (And similarly for Box.)

@rust-lang/libs, any throughts?

@SimonSapin SimonSapin added C-enhancement Category: An issue proposing an enhancement or a PR with one. A-allocators Area: Custom and system allocators A-collections Area: `std::collection` T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Oct 25, 2019
@alexcrichton
Copy link
Member

I personally think that this is a useful enough guarantee while also being flexible enough for us in the standard library that this should be fine to document.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-allocators Area: Custom and system allocators A-collections Area: `std::collection` C-enhancement Category: An issue proposing an enhancement or a PR with one. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

2 participants