RE: US-CERT Vulnerability Note VU#162289

[<Gerald dot Williams at infineon dot com>]

Robert Dewar wrote:
> An optimziation is dubious to me if
> 
> a) it produces surprising changes in behavior (note the importance of
> the word surprising here)
> 
> b) it does not provide significant performance gains (note the
> importance of the word significant here).
> 
> I find this optimization qualifies as meeting both criteria a) and b),
> so that's why I consider it dubious.

I don't think this is a particularly fruitful argument to be
having at this stage.

It's already been acknowledged that the source code is wrong
to assume that the compiler knows about wrapping of pointers.
The real issue at this stage is how to warn users who may be
using GCC and implicitly relying on its old behavior, without
unintentionally pushing people in the wrong direction. Since
this optimization is performed by many other compilers, the
ship has already sailed on this one, so to speak. [In fact,
after GCC does something to warn users about this, it'll be
much "safer" than those other compilers.]

I agree that on the face of it, it seems like you wouldn't
want to optimize away tests like this when you can know that
pointer arithmetic really does look the same as unsigned
arithmetic (for a particular architecture, etc.). However,
sometimes an optimization may enable thirty more, so I for
one am not going to argue against it. Especially not when
many other compilers do it also.

-Jerry

P.S. I'm having some déjà vu, recalling discussions back in
the GCC 2.7 days about whether it was really OK to change
the behavior for signed arithmetic to support devices with
saturation. We've come a long way since then.