> 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
> 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
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
> 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
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
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
