Guaranteeing it either wraps or immediately traps would also be a regression, by forbidding more efficient implementations that trap as late as possible by propagating overflow errors via poison bits or poison values. UBSan is explicitly not designed as efficient. It's difficult.
Conversation
I do think the standard should forbid treating signed overflow as something that is guaranteed to never happen in order to optimize further, and the same goes for other cases like this. It's near impossible to do that for memory safety issues without requiring safety though.
1
1
I think that's going to be a hard sell to compiler vendors — doesn't it mean people will have to rewrite their inner loops with size_t loop counters to get reasonable efficiency?
1
Clang and GCC both implement it for both signed and unsigned integer overflow. It's not a hard sell to them. It's impractical to use it for unsigned overflow largely because it's well-defined and there are lots of intended overflows that are not actually bugs in the software.
2
2
The standard permitting trapping on signed overflow for portable C code is useful regardless of what compilers do by default. A safer language would not only have memory / type safety but would consider integer overflow to be a bug unless marked as intended (Swift and Rust).
2
1
Considering it to be a bug doesn't mean that it actually MUST trap in production, but that it CAN trap. It should always trap in debug builds, and trapping in production is an option based on performance and availability vs. correctness decisions. It's a better approach.
2
1
In Rust, both signed and unsigned integer overflow is always considered a bug. Intended overflows need to be marked and it supports wrapping for both signed and unsigned via the appropriate APIs. It traps for unintended overflows in debug builds by default and can in production.
3
2
Yes, this is clearly the correct approach for a new language design, except that perhaps trapping for unintended overflows in production is the right approach too. But humans are going to be relying on existing C code until at least 2070, if not for as long as there are humans
1
It definitely makes sense to trap in production. Rust doesn't do it yet for performance reasons. Their plan is to enable trapping by default on architectures with much better support for it in hardware. Swift traps by default for release because it doesn't aim at the same niche.
2
1
Still, that's not the right solution for software that doesn't fail, just software that fails more predictably.
1
Definitely. The right solution in most cases is to use big integers unless there are very clear limits that are actually enforced. You still need limits for big integers or you are going to get dynamic runtime failures from running out of resources though.
So that means it's important for big integers to have first class support in the language, unlike a language like Java where they are ridiculously verbose. Language either needs to support user defined arithmetic types well or have a built-in type for it if they don't do that.