Skip to content

Clarify guarantees for Vec and String allocation #65801

New issue

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

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

Already on GitHub? # to your account

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::collections` 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::collections` 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.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-allocators Area: Custom and system allocators A-collections Area: `std::collections` 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