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

<deque>: Properly destroy (fancy) pointers to blocks in the internal map #2775

Merged
merged 13 commits into from
Jun 12, 2022

Conversation

frederick-vs-ja
Copy link
Contributor

The internal map array is fully constructed, so it should also be fully destroyed before deallocation.

Fixes #2769.

The map array is fully constructed just after allocation, so it should be fully destroyed before deallocation.
@frederick-vs-ja frederick-vs-ja requested a review from a team as a code owner June 9, 2022 06:29
stl/inc/deque Outdated Show resolved Hide resolved

size_t fancy_counter{};

template <class T>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is some pretty extensive work needed for a small test.

I am wondering whether it would make sense to reuse that machinery and test all containers for internal memory leaks?

@CaseyCarter CaseyCarter added the bug Something isn't working label Jun 9, 2022
stl/inc/deque Outdated Show resolved Hide resolved
Also place _Mysize() before _Newsize for consistency
for (; 0 < _Count; --_Count) {
for (; _Count > 0; --_Count) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No change requested: We generally try to avoid mixing unrelated cleanups into behavioral changes (as this increases the difficulty of reviewing and understanding source history). This isn't an ironclad rule - we're human and it's easier to fold changes into an existing PR, so a small amount of cleanup can be fine. In this case I think it's fine, but I wanted to mention it.

Comment on lines +140 to +142
friend bool operator==(const counting_ptr& lhs, const counting_ptr& rhs) = default;

friend auto operator<=>(const counting_ptr& lhs, const counting_ptr& rhs) = default;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No change requested: In product code, we conventionally don't name parameters of defaulted functions. On the other hand, in test code we're somewhat less rigorous about conventions. On the third hand, operator=(const counting_ptr&) didn't name its parameter, which is an argument for being locally consistent here. On the fourth and final hand, this isn't worth resetting testing. 😹

@StephanTLavavej
Copy link
Member

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

@StephanTLavavej StephanTLavavej self-assigned this Jun 10, 2022
@StephanTLavavej
Copy link
Member

I've resolved a trivial adjacent-add merge conflict in tests/std/test.lst.

@StephanTLavavej StephanTLavavej merged commit 9947dd9 into microsoft:main Jun 12, 2022
@StephanTLavavej
Copy link
Member

Thanks for fixing this correctness bug! 🐞 🎉 😸

@frederick-vs-ja frederick-vs-ja deleted the deque-block-ptrs branch June 12, 2022 11:43
fsb4000 pushed a commit to fsb4000/STL that referenced this pull request Aug 13, 2022
…l map (microsoft#2775)

Co-authored-by: Michael Schellenberger Costa <[email protected]>
Co-authored-by: Stephan T. Lavavej <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

<deque>: For allocators where allocator_traits<T>::pointer is an object, destructors aren't always called
4 participants