public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: Gabriel Dos Reis <gdr@integrable-solutions.net>
To: bkoz@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
Subject: Re: libstdc++/8230: Buggy allocator behaviour
Date: Wed, 20 Nov 2002 19:09:00 -0000	[thread overview]
Message-ID: <20021114203612.1656.qmail@sources.redhat.com> (raw)

The following reply was made to PR libstdc++/8230; it has been noted by GNATS.

From: Gabriel Dos Reis <gdr@integrable-solutions.net>
To: Benjamin Kosnik <bkoz@redhat.com>
Cc: bkoz@gcc.gnu.org, gcc-bugs@gcc.gnu.org, jkanze@caicheuvreux.com,
   gcc-gnats@gcc.gnu.org, libstdc++@gcc.gnu.org
Subject: Re: libstdc++/8230: Buggy allocator behaviour
Date: 14 Nov 2002 21:33:20 +0100

 Benjamin Kosnik <bkoz@redhat.com> writes:
 
 [...]
 
 | >This coredumps on my machine using current source.  The problem here is
 | >that std::allocator<> is not checking the bounds as required and it is
 | >lying.
 | 
 | Correct, with the pool allocators. If you add GLIBCPP_FORCE_NEW
 | everything is ok.
 
 Thanks!
 
 | See attached patch for a way to fix this with the pool allocators.
 | >
 | >I'm also nervous about:
 | >
 | >   std::vector<int> v;
 | >   v.resize(v.max_size());
 | >
 | >   v[v.max_size() - 1] = 2002;
 | >
 | >I didn't test it with your patch.
 | 
 | My patch is only for reserve, as it's expected to throw length_error.
 | I believe it's still correct, regardless of resolving this issue.
 
 Yes, you're right.
 
 | For resize, the above issue comes into play.
 | 
 | On a completely unrelated note, what's up with std::vector and all the gooey 
 | allocator typedefs? Ick.
 
 [ I'm not sure I understand correctly which part you're referring to.
   I'll try answer what I understood from your question.  Please don't
   hesitate to correct me if I'm on the wrong track.  ]
 
 Well, the allocator_type typedef game is what we've got to write to
 simulate "typedef template".  Basically one wants to be able to get an
 allocator for the familly of allocator supplied to std::vector<>.
 
 | The allocator_type typedef is always allocator, as far as I can tell.
 | And _Alloc_type (should be __underlying_allocator or whatever) seems
 | superfluous. Instead of typedefing the base type all the time, with g++
 | one can just use the name of the template proper.
 
 Probably not the name of the template but the name of the
 template-parameter _Alloc.  But, I suspect that for not duplicating
 the way the allocator is referred to, it is just safe to use
 _Base::allocator_type -- note that we have to typedef that name to
 allocator_type in std::vector<> anyway.
 
 Maybe Matt has better explanations.
 
 -- Gaby


             reply	other threads:[~2002-11-14 20:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-20 19:09 Gabriel Dos Reis [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-11-23  1:16 bkoz
2002-11-21 14:01 Richard Henderson
2002-11-21  4:06 Gabriel Dos Reis
2002-11-21  3:47 Matt Austern
2002-11-20 23:03 Gabriel Dos Reis
2002-11-20 18:20 Benjamin Kosnik
2002-11-20 18:19 Benjamin Kosnik
2002-11-20 18:02 Gabriel Dos Reis
2002-11-20  5:07 bkoz
2002-10-15  5:56 gdr

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=20021114203612.1656.qmail@sources.redhat.com \
    --to=gdr@integrable-solutions.net \
    --cc=bkoz@gcc.gnu.org \
    --cc=gcc-prs@gcc.gnu.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).