Hacker News new | past | comments | ask | show | jobs | submit login

> For the same reason we trap on integer division by zero.

The thing is I can hardly imagine a situation where a division by zero would be normal and expected, while having integers overflow as a normal part of a calculation is business as usual in many cases. Having to handle a trap (or disabling/enabling it dynamically) would slow things down way too much. Many crypto ciphers for instance specify operations "modulo 32" in order to take advantage of this "feature".

> To allow compilers (not just C) to emit safer code by default by removing the small but measurable instruction penalty.

Detecting overflow in asm is just testing the carry bit of the processor. A trap would be orders of magnitude slower on any modern architecture. You seem to be assuming that overflows are rare in C programs. I'm not sure this is true, but I have no hard data on that so who knows...




> Many crypto ciphers for instance specify operations "modulo 32" in order to take advantage of this "feature".

Which is one reason I'm specifically not advocating for doing away with nonsignaling modulo-2^2^n addition.

However, of all the addition operations in the gigabytes of object code on my hard drive, what percentage of them do you think actually encode the true desire of an application developer to perform wrapping arithmetic?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: