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, the code.
My evidence-free opinion is that this scenario is in fact more likely
than the apparently contrived example in the CERT note.
Ralph.
PS The CERT note refers to "existing programs" broken by the
optimisation. I wrote to their feedback address asking about the
"existing programs" and heard nothing back, which makes me suspect that
the authors of the note don't know of any, despite their claim.
> The GCC SC was aware of this CERT posting before it was public. Our
> feeling is that this is not a GCC bug, although it is something that
> we would like GCC to warn about. I talked to Ian Taylor and he
> agreed to work on the warning.
>
> Some other compilers do this optimization too, so compiling similar
> applications with them will also lead to the removal of the test.
> We've identified one specific highly-optimizing compiler that does
> this optimization. If you have information about other such
> compilers, please send it to me, and I will forward to CERT. We
> would like to counter the idea that GCC is unique in this regard.
> (In fact, I expect that the reason that this issue was found with GCC
> is that GCC is used so widely!)
>
> Here is the test program:
>
> int f(char *buf, int len) {
> len = 1 << 30;
> if (buf + len < buf)
> return 1;
>
> return 0;
> }
>
> If you know of a non-GCC compiler that optimizes away the test (so
> that the function always returns 0), please post here, and let me
> know the name, version number, command-line options, etc. you used to
> demonstrate that.
>
> Thanks,
>
