Sure, but then you deserve what you get...
Posted May 24, 2011 23:14 UTC (Tue) by
iabervon (subscriber, #722)
In reply to:
Sure, but then you deserve what you get... by marcH
Parent article:
What Every C Programmer Should Know About Undefined Behavior #3/3
Actually, I suspect that gcc actually transforms the condition to "val < 0x104030200". How would gcc, a C program, compute the result of a signed overflow without risking crashing? It's more comprehensible as "step 1 assumes that, because there is no signed overflow, the arbitrary-precision value of the expression 0x03020100 + (i*0x04040404) is the value of val; step 2 notices that the condition is always true due to the limited range of the variable."
This also avoids the issue that it would be really hard to determine that "val != 0x04030200" is always true without determining that the code actually hits a signed overflow.
Actually, the first transformed code is probably:
int *value;
int val;
for (val = 0x03020100; val < 0x104030200; val += 0x04040404, value++)
*value = val;
Eliminating "i" is reasonably likely to be huge on x86 come register allocation, so it's a good optimization if it works. And gcc can assume it works because the programmer can't let signed arithmetic overflow. Of course, at this point, it already doesn't work as expected; the second optimization just makes the assembly confusing. The second optimization is really for "if (size >= 0x100000000) return -EINVAL;" where the programmer cares about a 32-bit limit in code that could be built with either 32-bit or 64-bit ints; in some builds it's important, and in all builds it's correct, but the compiler can eliminate it in cases where it doesn't matter.
(
Log in to post comments)