This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [Patch] Fix vector wrt __len overflows
- From: Nathan Myers <ncm-nospam at cantrip dot org>
- To: libstdc++ <libstdc++ at gcc dot gnu dot org>
- Date: Tue, 19 Oct 2004 09:52:38 -0700
- Subject: Re: [Patch] Fix vector wrt __len overflows
- References: <417540BC.4030503@suse.de>
On Tue, Oct 19, 2004 at 06:28:44PM +0200, Paolo Carlini wrote:
> Hi,
>
> the below is tested x86-linux. Creating an appropriate testcase not
> thrashing most machines seems very difficult but the issue is rather
> clear and easy to fix. If nobody objects I will commit it very soon...
> const size_type __old_size = size();
> const size_type __len = __old_size != 0 ? 2 * __old_size : 1;
> + // When sizeof(value_type) == 1 and __old_size > size_type(-1)/2
> + // __len overflows: if we don't notice and _M_allocate doesn't
> + // throw we crash badly later.
> + if (__len < __old_size)
> + __throw_length_error(__N("vector::_M_insert_aux"));
Shouldn't we just try to allocate as much as we can, instead?
That hypothetical 16-bit machine might have 32-bit addresses and
be able to allocate a full 64K for each vector. In that case if
the last doubling would exceed size_t(-1) - E (for some E imposed
by malloc overhead), we should just try to grow to the maximum size
that we can succeed in allocating, probably that same size_t(-1) - E.
In an ideal world we might use binary-search to see precisely
how big we could grow it, but that seems excessive. If growing
to that maximum size fails, we might anyway try to grow by some
fixed amount instead, e.g. 1K.
Nathan Myers
ncm-nospam@cantrip.org