4 ms·
I had the same basic thought while reading this: the only alternative here is to interpret this sort of undefined behavior in a "different" way (such as the way
by commandlinefan 5y ago
I had the same basic thought while reading this: the only alternative here is to interpret this sort of undefined behavior in a "different" way (such as the way the K&R originally interpreted it) and leave it up the programmer to intuit what other assumptions the compiler is making on their behalf. Like... I can assume that the compiler will interpret:
if (i++ < i)
as
mov ax, i
inc ax
cmp ax, i
jge else
... but that's still me making a (reasonable?) assumption. The C spec essentially just says "don't program that way".
- Shikadi 5y agoOdd intuition, since you never store i back after incrementing. Also, I believe i++ might increment after the comparison rather than before, vs. ++i incrementing first
- commandlinefan 5y agoYou know what I mean.
- Shikadi 5y agoI actually don't, but maybe I just lack enough background knowledge on the discussion to understand your intent
- saghm 5y agoI think they're saying that the assembly translation doesn't store back `i`, whereas the C version does, so it's a not straightforward to assume that the assembly compiled from the C won't do that.
- commandlinefan 5y agoThe article talks about a similar code snippet being optimized out by the compiler because i++ can never be less than i originally was (unless you take into account the actual behavior of computers).
- int_19h 5y ago++ is itself a store.
- Shikadi 5y agoOh wow I totally missed the i++ < i Don't mind me