4 ms·
> [dropped] Representations for signed integers other than two's complement May I assume that there won't be signed int undefined behavior after C23? INT_MAX +
by blastonico 5y ago
> [dropped] Representations for signed integers other than two's complement
May I assume that there won't be signed int undefined behavior after C23? INT_MAX + 1 == INT_MIN?
- Someone 5y agoI 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.