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

Gabriel Dos Reis gdr@integrable-solutions.net
Mon Feb 7 16:42:00 GMT 2011


On Mon, Feb 7, 2011 at 10:17 AM, Mark Mitchell <mark@codesourcery.com> wrote:
> On 2/7/2011 2:49 AM, Gabriel Dos Reis wrote:
>
>>> Would you please provide a reference to the place where C++98 requires
>>> this check be performed by the compiler and/or run-time?
>>
>> It is hard to fathom what your point is.  That fix is OK for anything
>> other than C++98?
>
> I want to make sure that we don't impose C++0x requirements on C++98
> programs.  If, for example, C++0x requires new checks that were not
> required by C++98, then it would likely be inappropriate to add them (by
> default) for C++98, since that would slow down C++98 applications.

I believe nobody is arguing that C++0x semantics should be imposed
when C++98 is in effect.

However, I do not find your interpretation of C++98 to be accurate.
(As a matter of fact, this bug has already been filled several times
in the C++98 era.)

>
>> For the reference to C++98: see 5.3.4/10 (and 5.3.4/12 explanatory notes)
>
> It's hard to be sure that I'm looking at the same thing as you.  Are you
> referring to:
>
> "A new-expression passes the amount of space requested to the allocation
> function as the first argument of type std::size_t.  The argument shall
> be no less than the size of the object being created..."
>
> ?
>
> If so, I don't see evidence that this is a requirement on the
> implementation per se.

I am a slow man; can you explain in simple steps why that
paragraph is does not constitute a requirement on the implementation?

>  I think this could also be construed as a
> requirement on the application.

I strongly disagree.
The application has no knowledge *how* the compiler
computes the value it passes to the allocation function.
And it is precisely that incertitude that is exploited.  Only
the implementation knows.

>
> In any case, I think that what should be done here is to (a) implement
> the check, with a command-line option to control it, (b) set the default
> to off for all target, and (c) turn it on by default after discussion
> with the appropriate target maintainers, taking into account both the
> target and the operating system.  For example, it might make sense to
> turn this on by default for ARM GNU/Linux, but not for ARM EABI, given
> that the latter tends to be a much more space-constrained environment.
>
> --
> Mark Mitchell
> CodeSourcery
> mark@codesourcery.com
> (650) 331-3385 x713
>



More information about the Gcc-patches mailing list