Oh cool, another Chrome 0-day abusing integer overflow.

Neat.

Great.

Awesome.

@thephd this is possibly a controversial opinion, but in my view, integer overflows are _mostly_ dangerous when they cause a “second order” buffer overflow, for instance if the overflowed value is passed to malloc and you get a significantly smaller buffer than you were expecting. If we fix bounds safety, integer overflows aren’t nearly as dangerous as they are today even if we do nothing about them
@fay59 @thephd but hey: what if we just fixed both?
@fay59 @thephd I mean, you’re absolutely right, but also we know exactly how to fix both, so
@steve @thephd well, we know where to put the traps, but we don’t know how to help people navigate them. Having been on both sides of that work, putting the traps is the easy one unfortunately
@steve @thephd One example is that C code today can have while(i--) {…} to repeat {…} i times. If it’s unsigned and you trap on unsigned integer overflow (which you should because size calculations almost always are unsigned), this will blow up in your face
@steve @thephd there’s a big technical aspect to bounds safety and integer overflows, but there’s an even bigger aspect that things which used to work will stop working as a result, many of them being completely legal today. Swift had a free pass on that because there was no code to break when it decided integer overflow would trap. If you’re starting from nothing, this is (probably?) the right thing to do. When you have a 50plus-year legacy to support, the calculation is more difficult
@fay59 @thephd hey, what if we had a language that gave you both wrapping and trapping arithmetic?
@fay59 @thephd I’m being glib, but, like, we know what to do here.
@steve @thephd sure; the problem still isn’t the compiler solution, it’s that once you turn on the mode that has trapping arithmetic, it’s on you to identify all the places where you really actually did mean to use wrapping arithmetic