BTW,
It occurs to me that the optimisation is just as likely (if not more
likely) to remove security holes as it is to introduce them.
If someone writes comparison involving 'buf+len' because they
incorrectly ignored a possibility of 'buf+len' wrapping, then
the optimisation fixes, not breaks, th
Dear "Cert",
I originally raised this with you privately, but you are slow to
respond, so I am raising this again, more concisely, and CC'd to a less
private forum.
(a) Arithmetic overflows have historically been a significant source of
security vulnerabilities.
(b) Recent versions of gcc (along
> I am very interested in seeing how this optimization can remove
> arithmetic overflows.
int foo (char * buf, int n)
{
// buf+n may overflow of the programmer incorrectly passes
// a large value of n. But recent versions of gcc optimise
// to 'n < 100', removing the over
Robert,
You have failed to answer my original question, and I think have failed
to understand the point of the example.
The example shows that what you are claiming is a vulnerability in
162289 is in fact a security feature.
> that removes checks pointer arithmetic wrapping.
Just to be 100% c
> This clearly is insecure coding.
Yes, it was intended to be an example of what gcc does with bad code.
> When such assumptions are made ... the compiler may eliminate the bug
> in some cases giving the programmer a false feeling that "Oh! My code
> is bug free". The problem is that when the co
> Thanks for your further explanation of this optimization. Here is
> what I understand. Please correct me if I am wrong on any of these
> points:
Points 1...5, no quibble.
Now that you appear to admit that the issue is wrap-around and not a
length-check, this raises the question of whether th
