Gerald,
Comments below.
My
understanding is that it shouldn't, because the real issue here is
pointer arithmetic and the resulting type should always be a pointer.
I'm not sure what you mean by that last statement.
my understanding of the C99 standard is that adding an integer and a
pointer always results in a pointer. i'm not a compiler expert, but i
would think that the rules that apply to adding a pointer and an integer
of any signedness would be the same, and are different from the rules
that would apply to adding signed or unsigned integers.
VU#162289 only applies to pointer arithmetic. I need to go back and
check, but I don't believe the signedness of the integer involved is a
factor.
I think we've already established that those tests that would
print "BUG" aren't actually finding bugs in the compiler.
Sorry about the string literal "Bug". This was just an artifact from
the original program. I should have changed it to "optimization detected".
It
is not correct to assume that adding a value to a char pointer
will wrap around in the same way as if you added a value to an
unsigned number.
i think this depends on what you mean by "value".
You also cannot assume that adding a value to
a signed number will cause it to wrap. (GCC had optimized away
checks for the latter already. There are now reports that many
other compilers may optimize away both tests.)
ditto.
Are we in agreement on this? The fact that your example prints
"BUG!" seems to imply that it is invalid to optimize away these
tests, which it isn't.
i agree that the optimization is allowed by C99. i think this is a
quality of implementation issue, and that it would be preferable for
gcc to emphasize security over performance, as might be expected.
I was under the impression that the only issue here is that
there is a change in behavior. That's a very fine line to walk
when many other compilers do this. In fact, you can run into
the same change of behavior when switching from unoptimized
debug versions to optimized release versions. Recommending not
using a recent GCC as a possible remedy is dangerous (some
would probably say irresponsible).
this was only one of several solutions listed, and not the first one
listed. You will see that the Compliant Solution provided in the
referenced secure coding rule:
ARR38-C. Do not add or subtract an integer to a pointer if the resulting
value does not refer to an element within the array
<https://www.securecoding.cert.org/confluence/display/seccode/ARR38-C.+Do+not+add+or+subtract+an+integer+to+a+pointer+if+the+resulting+value+does+not+refer+to+an+element+within+the+array>
recommends modifying the code.
What you really mean is,
"Use an older GCC or some other compiler that is known not to
take advantage of this optimization."
i think we mean what we say, which is "*Avoid newer versions of gcc" and
*"avoiding the use of gcc versions 4.2 and later." i don't see any
verbiage that says "use a different compiler".
P.S. Has anyone checked how far back in the line of Microsoft
compilers you have to go to before they don't do this same
optimization
our tests shows that the 2005 version of the compiler does not perform
this optimization. i have not yet tested a newer version of the compiler.
rCs
