From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31961 invoked by alias); 18 Apr 2008 04:17:03 -0000 Received: (qmail 31809 invoked by uid 48); 18 Apr 2008 04:16:23 -0000 Date: Fri, 18 Apr 2008 04:17:00 -0000 Message-ID: <20080418041623.31808.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libstdc++/35969] GLIBCXX_DEBUG: list::merge triggers bad assert In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "greened at obbligato dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-04/txt/msg01273.txt.bz2 ------- Comment #5 from greened at obbligato dot org 2008-04-18 04:16 ------- Ok, the closest thing I could find is the 1998 draft standard: http://www.kuzbass.ru:8086/docs/isocpp/lib-containers.html#lib.sequences It says that splice "invalidates only the iterators and references to the spliced elements." There is no statement about iterators for merge. So it seems like the testcase is invalid not due to the merge but due to the splices. GLIBCXX_DEBUG mode doesn't catch the problem with the splices since the iterator is still considered valid after the splice. For example, the second splce doesn't assert on an invalid iterator being passed to it. Perhaps this was changed in the final standard. It seems odd to me that splice and merge would invalidate iterators as iterator stability is a prime reason for using std::list and these operations don't destroy any sequence values. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35969