[PATCH] fix singular iterator dereference in libstdc++ testcase 23_containers/list_modifiers.cc

[Doug Gregor]

On Tuesday, June 10, 2003, at 11:28 AM, Stephen M. Webb wrote:
> On June 10, 2003 12:18 pm, Doug Gregor wrote:
>> On Tuesday, June 10, 2003, at 08:15 AM, Stephen M. Webb wrote:
>>> The standard pretty explicitly states (in [23.2.2.3 (3)]) that
>>> pop_back()
>>> invalidates only iterators and references to the erased elements, and
>>> j is an
>>> iterator into list0101 that is not an iterator to the erased element.
>>> It
>>> should not be invalidated, and I would expect it to continue to work
>>> correctly in a conforming implementation, since there's nothing in 
>>> the
>>> standard that leads me to believe otherwise.
>>
>> The comments that pertain to iterator invalidation by container
>> operations only consider the "iterator" and "const_iterator" types for
>> a container, and not the "reverse_iterator" or 
>> "const_reverse_iterator"
>> types. Under this interpretation, the testcase is wrong, because it
>> fails when the latter two types are std::reverse_iterator<iterator> 
>> and
>
> I'm having difficulty finding the text in the standard that excludes 
> some of
> the legitimate iterator types into a list in that clause.  Perhaps I'm
> missing a DR that dealt with this issue.

I was unable to find a related DR.

> Following the principle of least surprise, I would expect any iterator
> obtained on a list to remain valid unless the element it is 
> referencing is
> erased.

So the point we disagree on is: are the reverse_iterator and 
const_reverse_iterator considered "iterators" in your sentence above? I 
believe they are not, because the reverse_iterator is just 
std::reverse_iterator<iterator> and const_reverse_iterator is 
std::reverse_iterator<const_iterator> (as stated in Table 66).

> You are correct in that given the current code, there is a dereference 
> of a
> destroyed pointer.  The question is, is this a latent bug in the
> implementation (my reading of the standard) that the test fails to 
> reveal or
> just a gotcha in the language (making use of reverse_iterator a 
> dangerous
> proposition)?  Does anyone else have any insight?

I think it's just a nasty little gotcha. Perhaps others have additional 
insight, but in any case if we are to discuss this further it should be 
on comp.std.c++.

	Doug