From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1564 invoked by alias); 3 Jan 2002 05:00:40 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 1494 invoked by uid 61); 3 Jan 2002 05:00:37 -0000 Date: Wed, 02 Jan 2002 21:00:00 -0000 Message-ID: <20020103050037.1493.qmail@sources.redhat.com> To: gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, pme@gcc.gnu.org, stevemw@place.org From: pme@gcc.gnu.org Reply-To: pme@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, pme@gcc.gnu.org, stevemw@place.org, gcc-gnats@gcc.gnu.org X-Mailer: gnatsweb 2.9.3 Subject: Re: libstdc++/1853: deallocates unowned memory within .pop_back() X-SW-Source: 2002-01/txt/msg00108.txt.bz2 List-Id: Synopsis: deallocates unowned memory within .pop_back() State-Changed-From-To: analyzed->closed State-Changed-By: pme State-Changed-When: Wed Jan 2 21:00:36 2002 State-Changed-Why: Like jdennett says, this is undefined behavior. To be strictly portable and correct, users should check for !x.empty() before removing elements from a container x. By default we shouldn't do sanity checking, I believe. The overhead imposed could be significant when pop_back is being called in a loop (which is what a double-ended queue could easily be used for). The same holds for other functions which behave badly when invoked in undefined situations. The penalty would be imposed for users which are correctly checking for empty containers, and would then be redundant. For 3.2 I hope to add some kind of super-safe debugging mode to the library. Speed and efficiency would go down the toilet, but we could catch cases like these. The guiding documentation for users would be: if your code works with this mode on, and it breaks without it, then you're doing something undefined. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=1853