alt.hn

4/30/2026 at 12:48:44 AM

Integer Overflow Checking Cost

 https://danluu.com/integer-overflow/

by iwsk

4/30/2026 at 12:53:53 AM

2014 (probably? Or 2008. Old and no date) Previously (166 points, 2014, 107 comments) https://news.ycombinator.com/item?id=8765714

by gnabgib

5/2/2026 at 7:04:46 AM

The archive says "12/14", so 2014 seems about right.

by aw1621107

5/3/2026 at 11:29:18 AM

It's gcc 4.x so more an archaeological curiosity than anything else. Did gcc have stdckdint back then?

by pseudohadamard

5/2/2026 at 8:52:25 AM

Definitely cheaper than using Electron I would say

by tcfhgj

5/2/2026 at 8:04:23 AM

In Swift (Apple’s C++ successor), the normal operators (`+`, `-`, `*`) trap on overflow for integer types. If you want twos complement wrapping, you can use `&+`, `&-`, and `&*`.

Given that Apple has been making its own CPU cores for years now, I suspect overflowing checking on Apple CPUs is virtually free (aside from code size).

by mayoff

5/2/2026 at 10:03:25 AM

> Given that Apple has been making its own CPU cores for years now, I suspect overflowing checking on Apple CPUs is virtually free (aside from code size).

Never make guesses based on a particular programming language. In Apple's own C documentation (https://developer.apple.com/documentation/xcode/integer-over...) it is stated that "Overflows result in undefined behavior." and enabling wrapping behaviour "may adversely impact performance", indicating that overflow detection is in fact not "virtually free".

by qayxc

5/2/2026 at 3:34:29 PM

"Enabling wrapping behaviour" for signed integers disallows a lot of optimizations based on signed overflow being undefined behaviour, which is a matter of language and compiler design. This says nothing about the cost of checked arithmetic itself on the CPU.

by debugnik

5/2/2026 at 3:51:33 PM

It does, though. UB and associated optimisations wouldn't be an issue if defined behaviour would not have an impact on performance. If the cost would be zero or negligible, the compiler wouldn't need to care and hence warnings like this wouldn't need to be explicitly stated.

by qayxc

5/2/2026 at 7:37:21 PM

And yet Swift doesn't rely on these optimizations, preferring to trap instead. Again, the guess above was about the CPU and we're conflating language-specific UB optimisations.

by debugnik

5/2/2026 at 1:18:09 PM

This approach isn’t good imo.

Zig also has a similar approach.

It is best to have ergonomic checked version of arithmetic functions and always use them when possible, and use the debug only checked versions on other places.

Performance of checked arithmetic will basically never matter around things like allocation in my experience

by ozgrakkurt

5/2/2026 at 10:06:29 AM

Code size (and branch table entries) are not free, of course. The other thing to note is that trapping operators often need to trap precisely which can lead to missed optimizations.

by saagarjha

5/2/2026 at 11:48:05 AM

One example of such an optimization is that overflow checking can prevent vectorization of code.

See for example this post: https://lemire.me/blog/2016/12/06/dont-assume-that-safety-co.... It is ancient, but I don’t see a reason why it would have become outdated.

by Someone

5/2/2026 at 4:59:11 PM

Vector instructions usually don't have overflow flags, so a compiler can't easily vectorize loops containing overflow checks. However, detecting overflows in integer operations requires only a bit of bitwise arithmetic. In my experiments, this lead to an overhead of only 7% for vectorized additions with overflow checks: https://cedardb.com/blog/vectorized_overflows/

by msichert

5/2/2026 at 6:24:59 PM

That's with a simple data operation and using a recent x86 vector ISA (AVX-512) that is only available on some systems, notably excluding any current Intel desktop CPU.

The real killer isn't the data operations, though, it's if the overflow checks interfere with converting the loop logic or data addressing to vectorizable form. Indexing with 32-bit signed int vs. unsigned int on a 64-bit platform in C is a classic case -- with unsigned the compiler cannot assume that addressing offsets don't wrap, which then prevents coalescing data accesses into vector loads and stores.

by ack_complete

5/2/2026 at 7:00:21 AM

[flagged]

by ardline