Robert C. Seacord wrote:
> Here is another version of the program (same compiler version/flags).
[...]
> void test_signed(char *buf) {
> signed int len;
[...]
> if((buf+len < buf) != ((uintptr_t)buf+len < (uintptr_t)buf))
> printf(" BUG!");
[...]
> void test_unsigned(char *buf) {
> unsigned int len;
[...]
> if((buf+len < buf) != ((uintptr_t)buf+len < (uintptr_t)buf))
> printf(" BUG!");
[...]
> The unsigned test was one we performed on the gcc versions. I added
the
> signed test, but it didn't make a difference on Visual Studio. 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.
I think we've already established that those tests that would
print "BUG" aren't actually finding bugs in the compiler. 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. 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.)
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 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). What you really mean is,
"Use an older GCC or some other compiler that is known not to
take advantage of this optimization."
-Jerry
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 (i.e., can we show irrefutably that this warning
should apply in the same degree to their compilers as well,
even without the "debug" versus "release" version argument)?
I suppose you only have to go as far back as the free version,
by inferring from the debug vs. release argument. :-)
