On Tue, Nov 30, 2010 at 3:38 PM, Joseph S. Myers
<jos...@codesourcery.com> wrote:
> On Tue, 30 Nov 2010, Florian Weimer wrote:
>
>> Mozilla seems to receive a report of an exploitable operator new[]
>> overflow every couple of months now. Obviously, this is not good.
>>
>> What is necessary so that GCC can fix this code generation issue?
>> I've created a patch, together with a test case, but it has not been
>> approved, nor have I been told how to change the patch to make it more
>> suitable for inclusion ("change the middle end type system so that
>> this can be expressed in a better way" is just not realistic for me,
>> and apparently anyone else):
>>
>> <http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00275.html>
>
> My suggestion at <http://gcc.gnu.org/ml/gcc-patches/2010-02/msg00315.html>
> wasn't to change the type system; it was to add new GENERIC / GIMPLE codes
> within the existing type system.
>
> Saturating arithmetic keeps coming up in one context or another. It's
> generally relevant if you want to exploit various instructions on various
> processors - or if you want to support vector intrinsics (which may
> include saturating operations) even when the vector instructions aren't
> present (see recent discussions of doing that for SSE intrinsics, for
> example). Sooner or later I expect someone will decide to do the work for
> at least one target.
>
> Related to the "operator new[]" issue, I'm concerned that saturation alone
> may not be enough to solve problems with overflows in allocation. If on a
> 32-bit system you allocate 2GB or more of memory, then differences between
> addresses in / just after that array cannot be calculated reliably as they
> may excess the range of ptrdiff_t. Thus actually malloc ought to reject
> allocations that take half or more of the address space, to avoid
> undefined behavior arising in the calling code (such allocations simply
> cannot be used reliably in C or C++). But I don't see anything in glibc's
> malloc to do so; it seems quite possible that it could allocate over 2GB
> in a single allocation on a 32-bit system. (See PR 45779, but I think the
> only sensible place to fix this is the implementation of malloc.)
>
The existing GCC behaviour is a bit more perverse than the
C malloc() case as in
new T[n]
there is no multiplication that could be credited to careless programmer.
The multiplication is introduced by GCC.
-- Gaby
