You'll find the quoted text below in section I. Introduction of the article Understanding Integer Overflow in C/C++ (emphases are mine):
Detecting integer overflows is relatively straightforward by using a modified compiler to insert runtime checks. However, reliable detection of overflow errors is surprisingly difficult because overflow behaviors are not always bugs. The low-level nature of C and C++ means that bit- and byte-level manipulation of objects is commonplace; the line between mathematical and bit-level operations can often be quite blurry. Wraparound behavior using unsigned integers is legal and well-defined, and there are code idioms that deliberately use it. On the other hand, C and C++ have undefined semantics for signed overflow and shift past bitwidth: operations that are perfectly well-defined in other languages such as Java. C/C++ programmers are not always aware of the distinct rules for signed vs. unsigned types in C, and may naively use signed types in intentional wraparound operations.1 If such uses were rare, compiler-based overflow detection would be a reasonable way to perform integer error detection. If it is not rare, however, such an approach would be impractical and more sophisticated techniques would be needed to distinguish intentional uses from unintentional ones.
I don't understand why compiler based detection would be impractical to detect wraparound operations on signed types, if such uses are not rare? Also, why would we need to distinguish between intentional and unintentional uses? Both are undefined behavior by the Standard.
Detecting signed integer overflows at runtime is no problem. New languages like Swift do it automatically and reliably.
The problem is: Although integer overflows are undefined behaviour in C and C++, there are tons and tons of code where integer overflows happen, and because the compiler silently ignores integer overflows, everything works just fine.
If you start detecting integer overflows, such uses will break the application. And of course these overflows won't happen when the developer runs the application, or a tester runs it, but only when the program is shipped to customers, who will get very, very angry if their application crashes at the most inappropriate and most costly time, just because you decided to disallow some undefined behaviour that worked just fine.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With