4 ms·
Signed integer overflow being UB enables compiler optimizations. Most famously, when compiling for (int i = 0; i < bound; i++) in an LP64 environment (i.e.,
by ameliaquining 8y ago
Signed integer overflow being UB enables compiler optimizations. Most famously, when compiling
for (int i = 0; i < bound; i++)
in an LP64 environment (i.e., one where the native machine word is 64 bits but int is 32 bits, as is the case in most modern compilers targeting most modern architectures), it allows i to be represented by a native machine word, increasing performance.
You can, and people constantly do, argue about whether this is worth it, but I suspect it's the primary reason why a lot of the committee didn't want to change this behavior.
- kazinator 8y agoIf it's okay to screw programs that make nonportable assumptions, then int should just be 64 bits. After all, int is supposed to be the machine's natural integer. The current fashion is that we like programs that assume int is 32 bits, and don't like ones that assume wraparound arithmetic.
- slededit 8y ago32-bit ints have a more compact encoding in x86 because it was assumed they would be the most common. The "native" size isn't a simple matter these days. Back in the old dark days of 8 and 16-bits common values regularly exceeded the size. But 4 billion is large enough to still be the default.
- brigade 8y agoHaving optimized very tight C loops which included manually promoting int types to intptr_t to avoid sign extension, I'll say emphatically that avoiding needless sign extension had no effect on my micro-benchmarks on modern wide CPUs, let alone my macro benchmarks.