Skip to content

The Vec should not needlessly overallocate capacity if it is guaranteed to fail. #31446

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
ghost opened this issue Feb 6, 2016 · 4 comments
Labels
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

@ghost
Copy link

ghost commented Feb 6, 2016

Current Vec / RawVec allocation strategy is to at least double the capacity on
reallocation. This leads to unnecessary panic when the new overallocated
capacity exceeds std::isize::MAX. If allocating std::isize::MAX would be
sufficient it should do so instead.

For example I would expect the following to work on 32-bit platform (provided
that there is sufficient amount of memory):

fn main() {
    let mut v = std::vec::from_elem(1 as u8, (std::isize::MAX / 2 + 1) as usize);
    v.push(1);
}
@apasel422 apasel422 added A-libs A-collections Area: `std::collections` labels Feb 6, 2016
@nagisa
Copy link
Member

nagisa commented Feb 6, 2016

Would’ve been fixed-ish by #29848?

@Gankra
Copy link
Contributor

Gankra commented Feb 7, 2016

I'm curious: what languages succeed or fail by this metric?

@ghost
Copy link
Author

ghost commented Feb 7, 2016

@nagisa as far as I can see that PR would have exactly the same problem.
Generally, the source of problem lies in a fact that the calculation of new
capacity is unaware on requirement that it should be less than std::isize::MAX,
which is checked only later in alloc_guard.

@gankro the GNU libstdc++ works fine in this respect. It seems more like
quality of implementation issue, than some strong requirement.

@steveklabnik steveklabnik added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. and removed A-libs labels Mar 24, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jul 24, 2017
@steveklabnik
Copy link
Member

Triage: I don't think anyone has addressed this issue.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
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

5 participants