libstdc++/646
pme@gcc.gnu.org
pme@gcc.gnu.org
Sun Apr 1 00:00:00 GMT 2001
The following reply was made to PR libstdc++/646; it has been noted by GNATS.
From: pme@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org, kzhang@vill.com, nobody@gcc.gnu.org
Cc:
Subject: Re: libstdc++/646
Date: 8 Feb 2001 21:00:41 -0000
Synopsis: stl map hangs while erasing end()
State-Changed-From-To: open->closed
State-Changed-By: pme
State-Changed-When: Thu Feb 8 13:00:41 2001
State-Changed-Why:
Stroustrup was wrong.
(How often do I get to say *that*? :-)
Given a container c, I don't know whether c.erase(c.end()) used to be
valid, but it isn't, and I suspect it never was. The constraints on
the single-iterator-argument of erase() include that the iterator may
be dereferenced, which end() cannot be. In the current implementation
of map<>, this leads to an infinite loop as we search for a non-NULL
child... of end()...
Somewhere around the 10th or 11th printing, Stroustrup notes this change
in his errata list:
pg 489 replace "Erasing end() is harmless." by "A call m.erase(b,e)
where e is m.end() is harmless (provided b refers to an element of
m or is m.end()). However, a call m.erase(p) where p is m.end() is a
serious error that could corrupt the container."
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=646&database=gcc
More information about the Gcc-prs
mailing list