Hacker News
points by Maxatar 3 days ago | 0 comments
No one is suggesting that every arithmetic operation is checked for overflow. The suggestion is that overflow is not undefined behavior. Getting rid of undefined behavior for overflow does not in anyway require that every operation is now checked, all it requires is specifying that the result of an arithmetic overflow depends on the platform and different platforms might produce different results.
[–] dwattttt 3 days ago
Defining the behaviour for overflow in the language doesn't suddenly mean the behaviour is what every program wanted. Fine that it has a defined result, but if that result isn't what you meant when you wrote a+b it's still a bug.

At a broad view, we get to a place where there's no "bug" when "what happens on overflow" is what the program(mer) wants.

[–] Maxatar 3 days ago
I have no idea how to parse your comment or how it relates to what I said.

All I said is that you can remove undefined behavior from signed overflow without having to introduce checks to every arithmetic operation and without having to specify any particular behavior or outcome. The technical term for this is "unspecified behavior" and the consequence of making overflow unspecified behavior is that the consequences of overflow, while still unspecified, must be bounded in space and time, unlike undefined behavior whose consequences are not required to be bounded in either space or time.

[–] dwattttt 3 days ago
I mean removing undefined behaviour from signed overflow isn't the problem. The problem is that when a programmer previously wrote a signed operation that could overflow, they didn't specify what behaviour they really needed.

You can define a behaviour today that they'll all get, but you can't define a behaviour that matches what each programmer needed when they wrote their operation. Some of them can wrap safely. Some of them would need to saturate. Others would need it to abort.

The problem isn't that the behaviour is undefined per se, it's that you can't tell afterwards which potential behaviour the programmer needs, and choosing one behaviour e.g. wrap will break everyone who actually needed saturating, or trapping, etc.