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

[Doug Gregor <dgregor at apple dot com>]

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