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