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