-
Notifications
You must be signed in to change notification settings - Fork 5
Fix condition in realloc() implementation of Vec #5
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
Fix condition in realloc() implementation of Vec #5
Conversation
Poolable and Realloc trait method implementations for Vec operate on the vector itself rather than its underlying buffer. This is why Poolable::capacity() implementation calls Vec::len() and Realloc::realloc() implementation uses Vec::resize() rather than Vec::reserve() or Vec::reserve_exact(). However, the condition checking whether the vector should be resized called Vec::len() rather than Vec::capacity(). Apparently it was an attempt to call Poolable::capacity(&self), but by default ambiguous call is resolved to Vec::capacity(). The problem is resolved by calling .len() explicitly. Regression test and assertions failing for byte-pool 0.2.2 are added.
This This was noticed before (well, yesterday), but never addressed: #4 |
Once this is merged, byte-pool 0.2.3 is needed to merge chatmail/async-imap#77 and then release a new deltachat-core-rust. |
@flub I pushed a second commit here as you said in chatmail/async-imap#77 (comment) that "byte-pool wanted to never have a Vec with capacity != len since that's wasteful, but at the time of writing this was not yet possible with the rust std api." |
self.reserve_exact(new_size - self.len()); | ||
debug_assert_eq!(self.capacity(), new_size); | ||
self.resize(new_size, T::default()); | ||
debug_assert_eq!(self.len(), new_size); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this assert seems a bit redundant, but doesn't do much harm either.
Hum, don't you have to do the reserve_exact thing also when initially creating the block? |
I have quickly checked, |
Poolable and Realloc trait method implementations for Vec
operate on the vector itself rather than its underlying buffer.
This is why Poolable::capacity() implementation calls Vec::len()
and Realloc::realloc() implementation uses Vec::resize() rather
than Vec::reserve() or Vec::reserve_exact().
However, the condition checking whether the vector should be resized
called Vec::len() rather than Vec::capacity().
Apparently it was an attempt to call Poolable::capacity(&self),
but by default ambiguous call is resolved to Vec::capacity().
The problem is resolved by calling .len() explicitly.
Regression test and assertions failing for byte-pool 0.2.2 are added.