public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: pme@gcc.gnu.org To: gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, pme@gcc.gnu.org, stevemw@place.org Subject: Re: libstdc++/1853: <deque> deallocates unowned memory within .pop_back() Date: Wed, 02 Jan 2002 21:00:00 -0000 [thread overview] Message-ID: <20020103050037.1493.qmail@sources.redhat.com> (raw) Synopsis: <deque> 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
next reply other threads:[~2002-01-03 5:00 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2002-01-02 21:00 pme [this message] -- strict thread matches above, loose matches on Subject: below -- 2001-12-28 15:51 pme 2001-06-12 14:14 bkoz 2001-04-01 0:00 stevemw
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20020103050037.1493.qmail@sources.redhat.com \ --to=pme@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ --cc=gcc-gnats@gcc.gnu.org \ --cc=gcc-prs@gcc.gnu.org \ --cc=stevemw@place.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).