User account creation filtered due to spam.

Bug 8230 - Buggy allocator behaviour
Summary: Buggy allocator behaviour
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: unknown
: P3 normal
Target Milestone: ---
Assignee: Benjamin Kosnik
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-10-15 05:56 UTC by Gabriel Dos Reis
Modified: 2003-07-25 17:33 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
jk.C (217 bytes, application/octet-stream)
2003-05-21 15:17 UTC, Gabriel Dos Reis
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gabriel Dos Reis 2002-10-15 05:56:01 UTC
std:allocator<T>::allocate(n) does not check for possible 
overflow before "folding" sizeof(T) * n.

Release:
all GCC releases.

Environment:
Plateform independent, though the program below
displays the buggy behaviour on IA32.
Comment 1 Benjamin Kosnik 2002-11-13 14:19:11 UTC
Responsible-Changed-From-To: unassigned->bkoz
Responsible-Changed-Why: Mine.
Comment 2 Benjamin Kosnik 2002-11-13 14:19:11 UTC
State-Changed-From-To: open->feedback
State-Changed-Why: I don't think this is an allocator::allocate issue per se. The member function reserve is only in std::vector and std::vector<bool>, and the standard says
    
    23.2.4.2 - vector capacity
    
    -4- Throws: length_error if n > max_size().* 
    
    Where allocator::allocate doesn't know what vector::max_size is. 
    
    This fix brings the code up to conformance, and is the best fix I think.
    
    -benjamin
Comment 3 Benjamin Kosnik 2002-11-13 22:15:17 UTC
From: bkoz@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: libstdc++/8230
Date: 13 Nov 2002 22:15:17 -0000

 CVSROOT:	/cvs/gcc
 Module name:	gcc
 Changes by:	bkoz@gcc.gnu.org	2002-11-13 14:15:17
 
 Modified files:
 	libstdc++-v3   : ChangeLog 
 	libstdc++-v3/include/bits: stl_bvector.h vector.tcc 
 	libstdc++-v3/testsuite/23_containers: vector_capacity.cc 
 
 Log message:
 	2002-11-13  Benjamin Kosnik  <bkoz@redhat.com>
 	
 	PR libstdc++/8230
 	* include/bits/vector.tcc (vector::reserve): Throw length_error if
 	requested size is bigger than max_size().
 	* include/bits/stl_bvector.h (vector<bool>::reserve): Same.
 	* testsuite/23_containers/vector_capacity.cc (test02): Add.
 
 Patches:
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&r1=1.1426&r2=1.1427
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/stl_bvector.h.diff?cvsroot=gcc&r1=1.17&r2=1.18
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/vector.tcc.diff?cvsroot=gcc&r1=1.2&r2=1.3
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/23_containers/vector_capacity.cc.diff?cvsroot=gcc&r1=1.3&r2=1.4
 
Comment 4 Benjamin Kosnik 2002-11-14 13:44:01 UTC
From: Benjamin Kosnik <bkoz@redhat.com>
To: Gabriel Dos Reis <gdr@integrable-solutions.net>
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: Thu, 14 Nov 2002 13:44:01 -0600

 This is a multi-part message in MIME format.
 
 --Multipart_Thu__14_Nov_2002_13:44:01_-0600_0841f4a0
 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: 7bit
 
 
 >20.4.1.1 allocator members
 >
 >2/
 >  pointer allocator(size_type n, allocator<void>::const_pointer = 0);
 >
 >7/
 >  Throws: bad_alloc if the storage cannot be obtained
 
 Got it, thanks for the clarification.
 
 >int main()
 >{
 >   try {
 >      std::allocator<int> alloc;
 >      const std::allocator<int>::size_type n = alloc.max_size();
 >      int* p = alloc.allocate(n + 1);
 >      p[n] = 2002;
 >      std::cout << p[n] << std::endl;
 >   } catch(const std::bad_alloc& e) {
 >      std::cerr << e.what() << std::endl;
 >   }
 >}
 >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.
 
 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.
 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.
 
 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. There's got to be a
 cleaner way to do a lot of this. Matt?
 
 best,
 benjamin
 --Multipart_Thu__14_Nov_2002_13:44:01_-0600_0841f4a0
 Content-Type: application/octet-stream;
  name="p.20021114-1"
 Content-Disposition: attachment;
  filename="p.20021114-1"
 Content-Transfer-Encoding: base64
 
 SW5kZXg6IHN0bF9hbGxvYy5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9jdnMvZ2NjL2djYy9saWJz
 dGRjKystdjMvaW5jbHVkZS9iaXRzL3N0bF9hbGxvYy5oLHYKcmV0cmlldmluZyByZXZpc2lvbiAx
 LjI1CmRpZmYgLWMgLXAgLXIxLjI1IHN0bF9hbGxvYy5oCioqKiBzdGxfYWxsb2MuaAkxOCBPY3Qg
 MjAwMiAyMDo1Mjo1NSAtMDAwMAkxLjI1Ci0tLSBzdGxfYWxsb2MuaAkxNCBOb3YgMjAwMiAxOToz
 NTo0NyAtMDAwMAoqKioqKioqKioqKioqKiogbmFtZXNwYWNlIHN0ZAoqKiogNjY5LDY4MSAqKioq
 CiAgICAgICAgY29uc3RfcG9pbnRlcgogICAgICAgIGFkZHJlc3MoY29uc3RfcmVmZXJlbmNlIF9f
 eCkgY29uc3QgeyByZXR1cm4gJl9feDsgfQogIAohICAgICAgIC8vIF9fbiBpcyBwZXJtaXR0ZWQg
 dG8gYmUgMC4gIFRoZSBDKysgc3RhbmRhcmQgc2F5cyBub3RoaW5nIGFib3V0IHdoYXQKISAgICAg
 ICAvLyB0aGUgcmV0dXJuIHZhbHVlIGlzIHdoZW4gX19uID09IDAuCiAgICAgICAgX1RwKgogICAg
 ICAgIGFsbG9jYXRlKHNpemVfdHlwZSBfX24sIGNvbnN0IHZvaWQqID0gMCkKICAgICAgICB7CiEg
 ICAgICAgICByZXR1cm4gX19uICE9IDAKISAgICAgICAgICAgPyBzdGF0aWNfY2FzdDxfVHAqPihf
 QWxsb2M6OmFsbG9jYXRlKF9fbiAqIHNpemVvZihfVHApKSkgOiAwOwogICAgICAgIH0KICAKICAg
 ICAgICAvLyBfX3AgaXMgbm90IHBlcm1pdHRlZCB0byBiZSBhIG51bGwgcG9pbnRlci4KLS0tIDY2
 OSw2OTMgLS0tLQogICAgICAgIGNvbnN0X3BvaW50ZXIKICAgICAgICBhZGRyZXNzKGNvbnN0X3Jl
 ZmVyZW5jZSBfX3gpIGNvbnN0IHsgcmV0dXJuICZfX3g7IH0KICAKISAgICAgICAvLyBOQjogX19u
 IGlzIHBlcm1pdHRlZCB0byBiZSAwLiAgVGhlIEMrKyBzdGFuZGFyZCBzYXlzIG5vdGhpbmcKISAg
 ICAgICAvLyBhYm91dCB3aGF0IHRoZSByZXR1cm4gdmFsdWUgaXMgd2hlbiBfX24gPT0gMC4KICAg
 ICAgICBfVHAqCiAgICAgICAgYWxsb2NhdGUoc2l6ZV90eXBlIF9fbiwgY29uc3Qgdm9pZCogPSAw
 KQogICAgICAgIHsKISAJX1RwKiBfX3JldCA9IDA7CiEgCWlmIChfX24pCiEgCSAgewohIAkgICAg
 Ly8gVGhlIHN0YW5kYXJkIG1hbmRhdGVzIHRoZSB1c2Ugb2YgOjpvcGVyYXRvciBuZXcsIGFuZAoh
 IAkgICAgLy8gdGhyb3dpbmcgYmFkX2FsbG9jIGlmIGFsbG9jYXRpb24gZmFpbHMuIEhvd2V2ZXIs
 IHRoaXMKISAJICAgIC8vIGltcGxlbWVudGF0aW9uIGFsbG93cyBvdGhlciBtZW1vcnkgYWxsb2Nh
 dGlvbiBzY2hlbWVzCiEgCSAgICAvLyBiZXNpZGVzIG9wZXJhdG9yIG5ldywgYW5kIHNvbWUgb2Yg
 dGhlbSBkb24ndCB0aHJvdwohIAkgICAgLy8gYmFkX2FsbG9jIGJ5IGRlZmF1bHQgaWYgdGhleSBm
 YWlsLiBUaHVzLCBhZGQgdGhlIGNoZWNrCiEgCSAgICAvLyBiZWxvdy4KISAJICAgIF9fcmV0ID0g
 c3RhdGljX2Nhc3Q8X1RwKj4oX0FsbG9jOjphbGxvY2F0ZShfX24gKiBzaXplb2YoX1RwKSkpOwoh
 IAkgICAgaWYgKCFfX3JldCkKISAJICAgICAgX190aHJvd19iYWRfYWxsb2MoImFsbG9jYXRvcjo6
 YWxsb2NhdGUiKTsKISAJICB9CiEgCXJldHVybiBfX3JldDsKICAgICAgICB9CiAgCiAgICAgICAg
 Ly8gX19wIGlzIG5vdCBwZXJtaXR0ZWQgdG8gYmUgYSBudWxsIHBvaW50ZXIuCg==
 
 --Multipart_Thu__14_Nov_2002_13:44:01_-0600_0841f4a0--

Comment 5 Benjamin Kosnik 2002-11-14 13:50:13 UTC
From: Benjamin Kosnik <bkoz@redhat.com>
To: Benjamin Kosnik <bkoz@redhat.com>
Cc: gdr@integrable-solutions.net, 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: Thu, 14 Nov 2002 13:50:13 -0600

 >The allocator_type typedef is always allocator, as far as I can tell.
 
 Ok, coffee break. This is wrong, by inspection. 
 
 >And _Alloc_type (should be __underlying_allocator or whatever) seems
 >superfluous. 
 
 The points about a simpler way still seem true though.
 
 -benjamin

Comment 6 Matt Austern 2002-11-14 14:10:55 UTC
From: Matt Austern <austern@apple.com>
To: Gabriel Dos Reis <gdr@integrable-solutions.net>
Cc: Benjamin Kosnik <bkoz@redhat.com>, 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: Thu, 14 Nov 2002 14:10:55 -0800

 On Thursday, November 14, 2002, at 12:39 PM, Gabriel Dos Reis wrote:
 
 > Benjamin Kosnik <bkoz@redhat.com> writes:
 >
 > | See attached patch for a way to fix this with the pool allocators.
 >
 > I agree with your patch.
 >
 > The following comment is for possible improvements.  What about using
 >
 >    if (__builtin_expect(__ret == 0, 0))
 >        __throw_bad_alloc("allocate::allocate");
 >
 > ?
 > That gives a hint to the compiler that the branch is expected to be
 > taken very unfrequently, and it should make scheduling accordingly.
 >
 > In general, I would like to see us starting using use 
 > __builtin_expect()
 > at places where we do checks for limits cases.  Thoughts?
 
 Two questions.
 
 First, is it known how much of a speedup this gives on typical 
 platforms?
 
 Second, if the answer to question 1 is "a lot": is there some sensible
 way to use this in the compiler itself?  I suppose it'd have to involve
 some ghastly macro hackery because of the bootstrap problem, but
 it we're talking big performance wins, it might be worth it.
 
 			--Matt
 

Comment 7 Gabriel Dos Reis 2002-11-14 15:59:43 UTC
From: Gabriel Dos Reis <gdr@integrable-solutions.net>
To: bkoz@gcc.gnu.org
Cc: 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 15:59:43 +0100

 bkoz@gcc.gnu.org writes:
 
 | Synopsis: Buggy allocator behaviour
 | 
 | Responsible-Changed-From-To: unassigned->bkoz
 | Responsible-Changed-By: bkoz
 | Responsible-Changed-When: Wed Nov 13 14:19:11 2002
 | Responsible-Changed-Why:
 |     Mine.
 | State-Changed-From-To: open->feedback
 | State-Changed-By: bkoz
 | State-Changed-When: Wed Nov 13 14:19:11 2002
 | State-Changed-Why:
 |     I don't think this is an allocator::allocate issue per se. The member function reserve is only in std::vector and std::vector<bool>, and the standard says
 
 Hi Benjamin,
 
   This issue is a conjugation of both std::allocator<> and
 std::vector<> ill-behaviour.  Fixing std::vector<> fixes a part of
 the problem (i.e. the testcase provided will pass), but leaves
 completely unfixed the std::allocator<> bits as required by the
 standard: 
 
 20.4.1.1 allocator members
 
 2/
   pointer allocator(size_type n, allocator<void>::const_pointer = 0);
 
 7/
   Throws: bad_alloc if the storage cannot be obtained
 
 20.4.1.1/11
   size_type max_size() const throw();
   returns the largest value N for which the call allocate(N, 0) might
   succeed. 
 
 Now consider
 
 int main()
 {
    try {
       std::allocator<int> alloc;
       const std::allocator<int>::size_type n = alloc.max_size();
       int* p = alloc.allocate(n + 1);
       p[n] = 2002;
       std::cout << p[n] << std::endl;
    } catch(const std::bad_alloc& e) {
       std::cerr << e.what() << std::endl;
    }
 }
 
 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.
 
 On fr.comp.lang.c++, I developed a theory to the effect that
 std::vector<> may always not check the bounds and still remain
 conformant *provided* that the allocator is doing the right thing.  
 
 |     23.2.4.2 - vector capacity
 |     
 |     -4- Throws: length_error if n > max_size().* 
 |     
 |     Where allocator::allocate doesn't know what vector::max_size is. 
 
 Agreed.
 
 |     
 |     This fix brings the code up to conformance, and is the best fix I think.
 
 It, however, does not address the std::allocator<> ill-behaviour.
 
 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.
 
 -- Gaby

Comment 8 Gabriel Dos Reis 2002-11-14 21:33:20 UTC
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

Comment 9 Gabriel Dos Reis 2002-11-14 21:39:50 UTC
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:39:50 +0100

 Benjamin Kosnik <bkoz@redhat.com> writes:
 
 | See attached patch for a way to fix this with the pool allocators.
 
 I agree with your patch.
 
 The following comment is for possible improvements.  What about using
 
    if (__builtin_expect(__ret == 0, 0))
        __throw_bad_alloc("allocate::allocate");
 
 ?
 That gives a hint to the compiler that the branch is expected to be
 taken very unfrequently, and it should make scheduling accordingly.
 
 In general, I would like to see us starting using use __builtin_expect()
 at places where we do checks for limits cases.  Thoughts? 
 
 -- Gaby

Comment 10 Gabriel Dos Reis 2002-11-14 23:27:17 UTC
From: Gabriel Dos Reis <gdr@integrable-solutions.net>
To: Matt Austern <austern@apple.com>
Cc: Benjamin Kosnik <bkoz@redhat.com>, bkoz@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
   jkanze@caicheuvreux.com, gcc-gnats@gcc.gnu.org, libstdc++@gcc.gnu.org,
   rth@redhat.com
Subject: Re: libstdc++/8230: Buggy allocator behaviour
Date: 14 Nov 2002 23:27:17 +0100

 Matt Austern <austern@apple.com> writes:
 
 [...]
 
 | > In general, I would like to see us starting using use 
 | > __builtin_expect()
 | > at places where we do checks for limits cases.  Thoughts?
 | 
 | Two questions.
 | 
 | First, is it known how much of a speedup this gives on typical 
 | platforms?
 
 I didn't make measurements by myself but I'm trusting its implementor
 (RTH) :-)
 
 Maybe RTH could provide us with some datapoint here?
 
 | Second, if the answer to question 1 is "a lot": is there some sensible
 | way to use this in the compiler itself?  I suppose it'd have to involve
 | some ghastly macro hackery because of the bootstrap problem, but
 | it we're talking big performance wins, it might be worth it.
 
 If the answer to the first question is "a lot", then I agree with you
 that it makes perfect sense to use it in the compiler itself.  I
 could imagine something along the lines
 
 #if !defined(__GNUC__) || __GNUC__ < 3  /* correct the version number */
 #  define __builtin_expect(EXP, PROB) EXP
 #endif
 
 in system.h or wherever appropriate.
 
 -- Gaby

Comment 11 Richard Henderson 2002-11-15 14:41:38 UTC
From: Richard Henderson <rth@redhat.com>
To: Gabriel Dos Reis <gdr@integrable-solutions.net>
Cc: Matt Austern <austern@apple.com>, Benjamin Kosnik <bkoz@redhat.com>,
   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: Fri, 15 Nov 2002 14:41:38 -0800

 On Thu, Nov 14, 2002 at 11:27:17PM +0100, Gabriel Dos Reis wrote:
 > Maybe RTH could provide us with some datapoint here?
 
 "It depends".
 
 > | Second, if the answer to question 1 is "a lot": is there some sensible
 > | way to use this in the compiler itself?  I suppose it'd have to involve
 > | some ghastly macro hackery because of the bootstrap problem, but
 > | it we're talking big performance wins, it might be worth it.
 > 
 > If the answer to the first question is "a lot", then I agree with you
 > that it makes perfect sense to use it in the compiler itself.  I
 > could imagine something along the lines
 > 
 > #if !defined(__GNUC__) || __GNUC__ < 3  /* correct the version number */
 > #  define __builtin_expect(EXP, PROB) EXP
 > #endif
 > 
 > in system.h or wherever appropriate.
 
 I don't think it's worth it, except _possibly_ in the 
 ENABLE_CHECKING macros.
 
 
 r~

Comment 12 Benjamin Kosnik 2002-11-16 17:16:32 UTC
From: bkoz@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: libstdc++/8230
Date: 16 Nov 2002 17:16:32 -0000

 CVSROOT:	/cvs/gcc
 Module name:	gcc
 Changes by:	bkoz@gcc.gnu.org	2002-11-16 09:16:32
 
 Modified files:
 	libstdc++-v3   : ChangeLog 
 	libstdc++-v3/include/bits: stl_alloc.h stl_vector.h vector.tcc 
 	libstdc++-v3/testsuite/20_util: allocator_members.cc 
 	libstdc++-v3/testsuite/23_containers: vector_capacity.cc 
 
 Log message:
 	2002-11-15  Benjamin Kosnik  <bkoz@redhat.com>
 	Gabriel Dos Reis  <gdr@integrable-solutions.net>
 	
 	PR libstdc++/8230
 	* include/bits/stl_alloc.h: Use builtin_expect for the most
 	obvious limit checks.
 	(__default_alloc_template::allocate): Check for null, throw
 	bad_alloc.
 	* include/bits/vector.tcc: Formatting tweaks.
 	* include/bits/stl_vector.h: Same.
 	* testsuite/20_util/allocator_members.cc (test02): Add.
 	* testsuite/23_containers/vector_capacity.cc (test03): Add.
 
 Patches:
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&r1=1.1431&r2=1.1432
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/stl_alloc.h.diff?cvsroot=gcc&r1=1.25&r2=1.26
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/stl_vector.h.diff?cvsroot=gcc&r1=1.29&r2=1.30
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/vector.tcc.diff?cvsroot=gcc&r1=1.3&r2=1.4
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/20_util/allocator_members.cc.diff?cvsroot=gcc&r1=1.2&r2=1.3
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/23_containers/vector_capacity.cc.diff?cvsroot=gcc&r1=1.4&r2=1.5
 
Comment 13 Benjamin Kosnik 2002-11-18 11:13:15 UTC
State-Changed-From-To: feedback->closed
State-Changed-Why: Fixed now.
Comment 14 Benjamin Kosnik 2002-12-02 20:01:55 UTC
From: bkoz@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: libstdc++/8230
Date: 2 Dec 2002 20:01:55 -0000

 CVSROOT:	/cvs/gcc
 Module name:	gcc
 Branch: 	gcc-3_2-branch
 Changes by:	bkoz@gcc.gnu.org	2002-12-02 12:01:55
 
 Modified files:
 	libstdc++-v3   : ChangeLog 
 	libstdc++-v3/include/bits: stl_bvector.h stl_vector.h 
 	libstdc++-v3/testsuite/23_containers: vector_capacity.cc 
 
 Log message:
 	2002-12-02  Benjamin Kosnik  <bkoz@redhat.com>
 	
 	PR libstdc++/8230
 	* include/bits/stl_vector.h (vector::reserve): Throw length_error if
 	requested size is bigger than max_size().
 	* include/bits/stl_bvector.h (vector<bool>::reserve): Same.
 	* testsuite/23_containers/vector_capacity.cc (test02): Add.
 
 Patches:
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_2-branch&r1=1.1057.2.159.2.58&r2=1.1057.2.159.2.59
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/stl_bvector.h.diff?cvsroot=gcc&only_with_tag=gcc-3_2-branch&r1=1.11.2.3&r2=1.11.2.3.2.1
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/stl_vector.h.diff?cvsroot=gcc&only_with_tag=gcc-3_2-branch&r1=1.17.2.4&r2=1.17.2.4.4.1
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/23_containers/vector_capacity.cc.diff?cvsroot=gcc&only_with_tag=gcc-3_2-branch&r1=1.3&r2=1.3.20.1
 

Comment 15 Benjamin Kosnik 2002-12-05 23:48:57 UTC
From: bkoz@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: libstdc++/8230
Date: 5 Dec 2002 23:48:57 -0000

 CVSROOT:	/cvs/gcc
 Module name:	gcc
 Branch: 	gcc-3_2-branch
 Changes by:	bkoz@gcc.gnu.org	2002-12-05 15:48:57
 
 Modified files:
 	libstdc++-v3   : ChangeLog 
 	libstdc++-v3/config: linker-map.gnu 
 	libstdc++-v3/docs/html/23_containers: howto.html 
 	libstdc++-v3/docs/html/ext: howto.html 
 	libstdc++-v3/include/backward: alloc.h 
 	libstdc++-v3/include/bits: c++config stl_alloc.h 
 	libstdc++-v3/src: stl-inst.cc 
 	libstdc++-v3/testsuite: abi_check.cc 
 	libstdc++-v3/testsuite/20_util: allocator_members.cc 
 	libstdc++-v3/testsuite/21_strings: capacity.cc 
 	libstdc++-v3/testsuite/23_containers: vector_capacity.cc 
 	libstdc++-v3/testsuite/ext: allocators.cc 
 
 Log message:
 	2002-12-05  Benjamin Kosnik  <bkoz@redhat.com>
 	
 	* config/linker-map.gnu: Put _S_force_new into GLIBCPP_3.2.2.
 	* testsuite/abi_check.cc: Add GLIBCPP_3.2.2.
 	
 	2002-12-05  Benjamin Kosnik  <bkoz@redhat.com>
 	Gabriel Dos Reis  <gdr@integrable-solutions.net>
 	
 	PR libstdc++/8230
 	* include/bits/stl_alloc.h: Use builtin_expect for the most
 	obvious limit checks.
 	(__default_alloc_template::allocate): Check for null, throw
 	bad_alloc.
 	* testsuite/20_util/allocator_members.cc (test02): Add.
 	* testsuite/23_containers/vector_capacity.cc (test03): Add.
 	
 	2002-12-05  Loren J. Rittle  <ljrittle@acm.org>
 	Brad Spencer  <spencer@infointeractive.com>
 	(provided alternate patch and improvements)
 	
 	PR libstdc++/8708
 	* docs/html/23_containers/howto.html (GLIBCPP_FORCE_NEW): Document
 	new environment variable which replaces all uses of __USE_MALLOC
 	macro.
 	* docs/html/ext/howto.html (GLIBCPP_FORCE_NEW): Likewise.
 	(__mem_interface): Remove all references to old internal typedef.
 	* include/backward/alloc.h (__USE_MALLOC): Remove it and all
 	guarded code.
 	* include/bits/c++config (__USE_MALLOC): Update related error
 	message and comment.
 	* include/bits/stl_alloc.h (__USE_MALLOC): Remove it and all
 	guarded code.  Update all related comments.
 	(__mem_interface): Unconditionally replace it with __new_alloc.
 	However, leave the typedef around in case anyone used it.
 	(__default_alloc_template<>::_S_force_new): New class static.
 	(__default_alloc_template<>::allocate, deallocate): Add
 	run-time controlled feature similar to what __USE_MALLOC code
 	path had provided.
 	* src/stl-inst.cc (__USE_MALLOC): Remove it and all
 	guarded code.
 	* testsuite/21_strings/capacity.cc: Remove reference to __USE_MALLOC.
 	Add documentation on GLIBCPP_FORCE_NEW environment variable.
 	* testsuite/ext/allocators.cc: Likewise.
 
 Patches:
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_2-branch&r1=1.1057.2.159.2.64&r2=1.1057.2.159.2.65
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/config/linker-map.gnu.diff?cvsroot=gcc&only_with_tag=gcc-3_2-branch&r1=1.5.2.6.4.5&r2=1.5.2.6.4.6
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/docs/html/23_containers/howto.html.diff?cvsroot=gcc&only_with_tag=gcc-3_2-branch&r1=1.20.2.1.2.1&r2=1.20.2.1.2.2
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/docs/html/ext/howto.html.diff?cvsroot=gcc&only_with_tag=gcc-3_2-branch&r1=1.18.8.2.2.1&r2=1.18.8.2.2.2
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/backward/alloc.h.diff?cvsroot=gcc&only_with_tag=gcc-3_2-branch&r1=1.11&r2=1.11.14.1
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/c++config.diff?cvsroot=gcc&only_with_tag=gcc-3_2-branch&r1=1.278.2.155.2.133&r2=1.278.2.155.2.134
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/stl_alloc.h.diff?cvsroot=gcc&only_with_tag=gcc-3_2-branch&r1=1.16.2.3&r2=1.16.2.3.4.1
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/src/stl-inst.cc.diff?cvsroot=gcc&only_with_tag=gcc-3_2-branch&r1=1.11.2.2&r2=1.11.2.2.4.1
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/abi_check.cc.diff?cvsroot=gcc&only_with_tag=gcc-3_2-branch&r1=1.2.2.9&r2=1.2.2.10
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/20_util/allocator_members.cc.diff?cvsroot=gcc&only_with_tag=gcc-3_2-branch&r1=1.2&r2=1.2.22.1
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/21_strings/capacity.cc.diff?cvsroot=gcc&only_with_tag=gcc-3_2-branch&r1=1.6.2.1.4.1&r2=1.6.2.1.4.2
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/23_containers/vector_capacity.cc.diff?cvsroot=gcc&only_with_tag=gcc-3_2-branch&r1=1.3.20.1&r2=1.3.20.2
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/ext/allocators.cc.diff?cvsroot=gcc&only_with_tag=gcc-3_2-branch&r1=1.1&r2=1.1.22.1