4 ms·
I doubt it, and wouldn’t want it. It would break all kinds of optimizations. For example, with wrapping for(int i = 0; i <= m; i++) { foo(); } Wouldn’t term
by Someone 5y ago
I doubt it, and wouldn’t want it. It would break all kinds of optimizations. For example, with wrapping
for(int i = 0; i <= m; i++) { foo(); }
Wouldn’t terminate if m = INT_MAX. That means compilers either have to special-case that value, or can’t use the loop instructions of some CPUs (M68000 has “decrement and branch if larger than zero”, for example)
Also, with wrapping, a[i] and a[i+1] aren’t guaranteed to be adjacent. That can make auto-vectorisation difficult.
- hfsrgbcfuknbft 5y agoThose things are very subtle and complex, so I'm not 100% sure, but I think your first example is not great: For example, with wrapping for(int i = 0; i <= m; i++) { foo(); } Wouldn’t terminate if m = INT_MAX. This is undefined behavior in the current standard when m = INT_MAX. The condition i <= m is always true and i will overflow. So it could result in an infinite loop (or worse). AFAICT, with wrapping signed ints, it would infinite loop but at least not yield UB?
- Someone 5y agoYes, for m = INT_MAX and wrapping signed int, it is undefined behavior. Because of that, the compiler is allowed to assume m ≠ INT_MAX, and that can mean it can generate more efficient and/or smaller code. Assuming m ≠ INT_MAX isn’t (considered to be [1]) a big loss because chances are the programmer who wrote that didn’t intend to write an infinite loop. [1] of course, is an opinion, but it’s the opinion the standards writers have had for decades.