This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: operator new[] overflow (PR 19351)
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Joe Buck <Joe dot Buck at synopsys dot com>
- Cc: Florian Weimer <fw at deneb dot enyo dot de>, Chris Lattner <clattner at apple dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Thu, 2 Dec 2010 16:47:30 -0600
- Subject: Re: operator new[] overflow (PR 19351)
- References: <87vd3eqzvg.fsf@mid.deneb.enyo.de> <Pine.LNX.4.64.1011302127210.14117@digraph.polyomino.org.uk> <AANLkTima1zd5tMx80G1-NB1UJ00tOF8=9iYJDxAAfYoc@mail.gmail.com> <20101130231211.GI13905@synopsys.com> <4FB8FB3B-2F0F-408C-A548-ADF7CE52A4A0@apple.com> <87eia0ell9.fsf@mid.deneb.enyo.de> <20101202202014.GI9549@synopsys.com>
On Thu, Dec 2, 2010 at 2:20 PM, Joe Buck <Joe.Buck@synopsys.com> wrote:
> On Wed, Dec 01, 2010 at 10:26:58PM -0800, Florian Weimer wrote:
>> * Chris Lattner:
>>
>> > On overflow it just forces the size passed in to operator new to
>> > -1ULL, which throws bad_alloc.
>>
>> This is also what my patch tries to implement.
>
> Yes, but Chris's code just checks the overflow of the multiply. ?Your
> patch achieves the same result in a more complex way, by
> computing the largest non-overflowing value of n in
>
> new T[n];
>
> and comparing n against that. ?Even though max_size_t/sizeof T is a
> compile-time constant, this is still more expensive.
I would expect max_size_t/sizeof(T) to be actually an integer
constant that n is compared against. I would be surprised
if that one-time comparison is noticeable in real applications that
new an array of objects.
>
>