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


             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: link
Be 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).