This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch] Fix vector wrt __len overflows


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]