This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Integer overflow in operator new
2007/4/9, Lawrence Crowl <crowl@google.com>:
On 4/7/07, Joe Buck <Joe.Buck@synopsys.com> wrote:
> Consider an implementation that, when given
>
> Foo* array_of_foo = new Foo[n_elements];
>
> passes __compute_size(elements, sizeof Foo) instead of
> n_elements*sizeof Foo to operator new, where __compute_size is
>
> inline size_t __compute_size(size_t num, size_t size) {
> size_t product = num * size;
> return product >= num ? product : ~size_t(0);
> }
>
> This counts on the fact that any operator new implementation has to
> fail when asked to supply every single addressible byte, less one.
This statement is true only for linear address spaces. For segmented
address spaces, it is quite feasible to have a ~size_t(0) much smaller
than addressable memory.
We've working in linear address spaces.
How for segmented address spaces? You give me examples.
The optimization above would be wrong for such machines because
the allocation would be smaller than the requested size.
To request a size of ~size_t(0) is to request a size
of 0xFFFFFFFF or 0xFFFFFFFFFFFFFFFFULL that the allocator will always
"sorry, there is not memory of 0xFFFFFFFF or 0xFFFFFFFFFFFFFFFFULL bytes.
> It would appear that the extra cost, for the non-overflow case, is
> two instructions (on most architectures): the compare and the
> branch, which can be arranged so that the prediction is not-taken.
That is the dynamic count. The static count, which could affect
density of cache use, should also include the alternate return value.
--
Lawrence Crowl
With CoreDuo, the density of cache use is not our problem because there are
L2 caches of 2 MiB! 4 MiB! and even more 6 MiB!!!.
Our main problem is to reach the maximum performance for future days.
J.C. Pizarro