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

Gabriel Dos Reis gdr@integrable-solutions.net
Sun Feb 6 01:20:00 GMT 2011


On Sat, Feb 5, 2011 at 4:20 PM, Mark Mitchell <mark@codesourcery.com> wrote:
> On 2/1/2011 1:40 PM, Florian Weimer wrote:
>
>>>> With this change, the size calculations are performed using
>>>> saturating arithmetic.  If the value cannot be represented exactly,
>>>> ::operator new(size_t) is invoked with size_t(-1)
>
> Purely as a point of semantic clarity, instead of talking about
> size_t(-1) we should be talking about std::limits<size_t>::max().  It
> was confusing to me to think about using a negative value in this context.

It could be argued that '-1' has always been C's way or writing the
max value of an unsigned integer value.

>
> 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.  In general, in C/C++, we don't check for overflow, leaving

Except that in this specific case, it is a check mandated by the C++ standard
semantics.  I don't believe we are doing the C++ community a service by
pretending that GCC needs to faultly implement the standard because some
competitors fail to do their homework.  On the contrary, I believe this is
an opportunity for GCC to show the way.

If there is a need for GCC to compete with faulty generated code, we can have
a command line switch for that, but it the default should be to implement
the standard semantics.

> that to the application; I don't see a reason that it's inherently more
> important to have the compiler generate checking code for new than
> elsewhere.

because the C++ standard says we should, and not doing it introduces
a security hole.

>
> But, it does seem like a useful mode for some applications.  So, it
> makes sense to me to add an option for this.

We should probably have the command line switch as you suggest,
but the default should generate the check.

>
> Thank you,
>
> --
> Mark Mitchell
> CodeSourcery
> mark@codesourcery.com
> (650) 331-3385 x713
>



More information about the Gcc-patches mailing list