>>>>> On 2007-04-06 16:12 PDT, Lawrence Crowl writes:
Lawrence> Asking programmers to write extra code for rare
Lawrence> events, has not been very successful.
Well put Lawrence, I agree; I didn't expect strong opposition.
I doubt we'd find much code in the wild that checks for integer
overflow before every 'new'. I'd like to reiterate that the
equivalent calloc issue was treated as a serious vulnerability and
fixed right away.
>From the programmer's point of view, the multiplication isn't
obvious. For all they know, it's a 'for' loop that iterates per
element, allocating (sizeof object) bytes in each iteration. So
it's not obvious why a check would even be necessary to a typical
user.
I would also note that all non-char uses of operator new that I
looked at in gcc's C++ headers are lacking integer overflow
checks.
Lawrence> It would be better if the compiler incorporated this
Lawrence> check into operator new, though throwing an
Lawrence> exception rather than asserting. The compiler
Lawrence> should be able to eliminate many of the
Lawrence> conditionals.
Indeed, recent research has found that even checking for overflow
on *every arithmetic operation* is only a 5% run-time overhead. A
default check on only 'operator new' invocations is quite cheap -
a single jump-if-overflow instruction that fares well with branch
prediction. Handling the overflow case can be moved faraway so it
doesn't affect instruction cache performance.
Fixing it in user code at call sites is cumbersome - there's no
way to wrap a macro around 'operator new', no way to do it in
custom 'operator new' since the implicit multiplication has
already occurred by then. It would have to be an explicitly typed
check at every use of 'operator new'.
--
Karl 2007-04-06 18:15
