Florian Weimer writes:
>Yeah, but that division is fairly expensive if it can't be performed
>at compile time.  OTOH, if __compute_size is inlined in all places,
>code size does increase somewhat.

Well, I believe the assumption was that __compute_size would be inlined.
If you want to minimize code size and avoid the division then a library
function something like following might work:

        void *__allocate_array(size_t num, size_t size, size_t max_num) {
                if (num > max_num)
                        size = ~size_t(0);
                else
                        size *= num;
                return operator new[](size);
        }

GCC would caclulate the constant "~size_t(0) / size" and pass it as the
third argument.  You'ld be trading a multiply for a couple of constant
outgoing arguments, so the code growth should be small.  Unfortunately,
you'd be trading what in most cases is a fast shift and maybe add or
two for slower multiply.

So long as whatever switch is used to enable this check isn't on by
default and its effect on code size and speed is documented, I don't
think it matters that much what those effects are.  Anything that works
should make the people concerned about security happy.   People more
concerned with size or speed aren't going to enable this feature.

                                        Ross Ridge

Reply via email to