From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27510 invoked by alias); 14 Nov 2002 19:46:05 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 27477 invoked by uid 71); 14 Nov 2002 19:46:04 -0000 Date: Wed, 20 Nov 2002 18:19:00 -0000 Message-ID: <20021114194604.27476.qmail@sources.redhat.com> To: bkoz@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Benjamin Kosnik Subject: Re: libstdc++/8230: Buggy allocator behaviour Reply-To: Benjamin Kosnik X-SW-Source: 2002-11/txt/msg00695.txt.bz2 List-Id: The following reply was made to PR libstdc++/8230; it has been noted by GNATS. From: Benjamin Kosnik To: Gabriel Dos Reis 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::const_pointer = 0); > >7/ > Throws: bad_alloc if the storage cannot be obtained Got it, thanks for the clarification. >int main() >{ > try { > std::allocator alloc; > const std::allocator::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 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--