Re: libstdc++/8230: Buggy allocator behaviour

[Benjamin Kosnik <bkoz@redhat.com>]

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

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--