[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