In the machine code output by the compiler, it's perfectly well defined what an out-of-bounds access or use-after-free will do, and to what, although of course it depends on runtime state. It's just undefined in the input C code.
Conversation
That's not a relevant response related to the thread. He states that he wants an optimizing compiler with a comparable amount of optimization, where the programmer is writing code for an abstract machine and the compiler is making transforms that preserve abstract semantics.
1
That wasn't my interpretation of his Tweet at the time, but on looking at further context, I think you are correct
1
I would definitely say that the standard should not say things are 'undefined' but rather come up with sensible constraints on how it should be implemented. Guaranteeing that signed overflow wraps would be a regression for safe implementations by forbidding them from trapping.
2
1
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.
1
1
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.
What's your disagreement with Rust's overflow behavior?
1
Show replies
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
Show replies
It doesn't trap by default for release builds, and code doing it is considered buggy, but it's not 'undefined' code. Trapping is optional. Optimization doesn't assume signed overflow never happens, because it doesn't mark signed arithmetic with nsw (no signed wrap) like Clang.