[PR19351, C++] Fix heap overflow in operator new[]

[Richard Guenther]

On Mon, Feb 7, 2011 at 7:27 AM, Florian Weimer <fw@deneb.enyo.de> wrote:
> * Mark Mitchell:
>
>> On 2/6/2011 3:17 AM, Richard Guenther wrote:
>>
>>>>> This doesn't seem like a good default to me.  It will penalize code that
>>>>> doesn't need the check and cause GCC to be perceived negatively in
>>>>> space-constrained environments; we'll generate worse code that competing
>>>>> compilers.
>>>>
>>>> Competing compilers have performed the check for several years.
>>
>> Which ones?
>
> Microsoft and HP have announced fixes.  I think Oracle has addressed
> it, too, but I would have to check again.
>
>> And are you looking at compilers used for embedded systems,
>> or for workstations/servers, or both?
>
> Sorry, no embedded targets here.  (I think comparison with
> traditionally broken compilers is not very helpful, BTW.)
>
> Compared to previous GCC versions, the code is not really nice, but
> not too bad either (load of a constant, comparison and conditional
> branch, plus load of -1 and a jump).  Fortunately, the code generated
> for operator new[] is not very compact to start with because the
> multiplication happens in the caller.
>
> The case which really, really suffers is allocation of arrays of VLAs,
> but this is an accidental GCC extension, rarely used if ever.

In the m32c assembly it looks like there are two allocation calls,
is this emitted this way from the frontend or just result of optimization?
(that's not ideal for later optimizers nor code-size)

Btw, I'd really like that C++ people would draft a new entry into libsupc++
that defers size calculation to the library.  Eventually using such
entry would even be ABI compatible(?) and can address the C++0x requirement
of raising a different exception.

Richard.