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

["Stephen M. Webb" <stephen dot webb at bregmasoft dot com>]

On June 10, 2003 12:18 pm, Doug Gregor wrote:
> On Tuesday, June 10, 2003, at 08:15 AM, Stephen M. Webb wrote:
> > On June 9, 2003 06:21 pm, Doug Gregor wrote:
> >> In the testcase 23_containers/list_modifiers.cc, the function test01()
> >> contains this block of code:
> >>
> >>    list0101.pop_back();          // list should be [2 1]
> >>    VERIFY(list0101.size() == 2);
> >>    VERIFY(T::dtorCount() == 1);
> >>    VERIFY(i->id() == 1);
> >>    VERIFY(j->id() == 1); // INVALID
> >>    VERIFY(k->id() == 1);
> >
> > 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.

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.

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?

-- 
Stephen M. Webb