[PATCH] Add assertion to _Rb_tree::erase to check for end iterators

[Jonathan Wakely <jwakely at redhat dot com>]

This adds assertions to catch assoc.erase(assoc.end()) when
_GLIBCXX_ASSERTIONS is defined. Without the assertion it usually leads
to a double free, which leads to termination for some mallocs anyway.

Because the erase(first, last) form called erase(first++) in a loop
I've changed that to bypass it and go straight to _M_erase_aux(first++),
so it doesn't do the assertion on every iteration of the loop. That
means the assertion won't fail in a case like this:

   std::set<int> s1, s2;
   s1.erase(s1.begin(), s2.end());

If we checked the assertion then when we reached the end of s1 we'd
abort, rather than try to keep incrementing the first iterator until
we reach the end of the other container (which will never happen). I
think this mistake is much less common, and checking the assertion on
every iteration isn't worth it. (The full-fat Debug Mode still catches
that mistake).

The erase(const Key&) form also called erase(iter) in a loop, and in
that case we know that iter != end() for all calls, so the assertion
is definitely not valuable.

	* include/bits/stl_tree.h (_Rb_tree::_M_erase_aux(const_iterator)):
	Add assertion for undefined argument.
	(_Rb_tree::_M_erase_aux(const_iterator, const_iterator)): Call
	_M_erase_aux directly instead of through erase.
	(_Rb_tree::_M_erase_aux(const Key&)): Likewise.
	* testsuite/23_containers/map/modifiers/erase/end_neg.cc: New test.

There's also a second patch to re-use the Doxygen comments for
erase(const_iterator) for the erase(iterator) overloads.

Tested x86_64-linux, committed to trunk.

Attachment: patch.txt
Description: Text document

Attachment: p2.txt
Description: Text document