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
next 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).