From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30783 invoked by alias); 27 Mar 2007 03:03:52 -0000 Received: (qmail 30682 invoked by uid 48); 27 Mar 2007 03:03:38 -0000 Date: Tue, 27 Mar 2007 03:03:00 -0000 Subject: [Bug libstdc++/31370] New: resizing bugs in std::vector X-Bugzilla-Reason: CC Message-ID: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "gcc at severeweblint dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-03/txt/msg02533.txt.bz2 Pre-4.0, vector had a bunch of nasty error cases when resizing overflowed a size_t. Change 89377 fixed some of them. But 1) vector's copy (yuck) of the relevant functions weren't updated 2) vector's max_size is incorrect. currently it is set to the maximum size_t. but because vector's iterators aren't directly pointers, and the iterator arithmetic takes ssize_t as arguments, it can't tolerate sizes that don't fit in an ssize_t. because of the round up to the nearest word, the correct max_size is SIZE_MAX rounded down to the nearest word. 3) if doubling a vector size exceeds max_size, the code will go ahead and ask the allocator for it. It seems nicer to clamp the size to max_size, although a bad_alloc is to be expected either way. I'd mostly argue that the vector code should clamp at max_size to avoid relying on the allocator to range check properly. -- Summary: resizing bugs in std::vector Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at severeweblint dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31370