On Fri, Apr 06, 2007 at 06:51:24PM -0500, Gabriel Dos Reis wrote: > David Daney <[EMAIL PROTECTED]> writes: > > | One could argue that issuing some type of diagnostic (either at > | compile time or run time) would be helpful for people that don't > | remember to write correct code 100% of the time. > > I raised this very issue a long time ago; a long-term GCC contributor > vocally opposed checking the possible overflow. I hope something will > happen this time.
I don't like slowing programs down, but I like security holes even less. If a check were to be implemented, the right thing to do would be to throw bad_alloc (for the default new) or return 0 (for the nothrow new). If a process's virtual memory limit is 400M, we throw bad_alloc if we do new int[2000000], so we might as well do it if we do new int[2000000000]. There would be no reason to use a different reporting mechanism. There might be rare cases where the penalty for this check could have an impact, like for pool allocators that are otherwise very cheap. If so, there could be a flag to suppress the check.
