Date: Wed, 03 Sep 2025 14:07:50 -0700
I’ve replied by points below, but I just want to address the core of your argument.
Your core argument is “signed overflow is always an error/bug”.
Declaring “signed overflow is UB” does not support that point of view.
The correct way to say “signed overflow is an error” is to say “signed overflow is erroneous behavior”. That makes it explicit that the overflow is an error, and it permits developers to rely on consistent and deterministic behavior, rather than dealing with an adversarial compiler that is blindly assuming that it cannot happen.
> On Sep 3, 2025, at 1:13 PM, Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> If something is UB in the standard, the implementations can define it to be something specific instead. That is standards compliant and not a new dialect, as long as the code does not depend on that outcome.
Yes, but the code is wrong even if it is correct under your specific dialect. You cannot say “I am relying on this specific behavior” and then say “I am writing C++”, because your “correct” code is incorrect per standard C++, another compiler results in your code invoking UB.
> > Because of that code that is correct with that flag, is not correct C++
> But that is the point of it. Signed overflow has not correct inputs. The preconditions are wrong. An implementation (and its flags) can choose, what happens under those circumstance.
I know that C++ says there is no correct input. Literally the entire point of what I have been saying, is that the only reason you are able to say "Signed overflow has not correct inputs” is because the specification has defined it that way. That’s a tautological argument, “this is undefined because we have said it is undefined”. I am saying “we should not be saying well defined behavior is undefined behaviour”.
> That is similar as if you have a contract violation for the contracts feature.
Yes, and I argued strongly for contract violations to be an error.
> A program error was detected and it can be configured, what happens in that case.
I’m not sure if you’re talking about contracts (with their own issues w.r.t permitting UB) or overflow UB where the entire point is that the overflow is not being detected, the compiler is just pretending it cannot happen.
> The program is not correct in the first place, if it comes to such an error.
Again, the program is only wrong because we have said it is wrong. You are saying we should continue to repeat choices made in the past that are demonstrably bad for program safety, Even though there is literally no reason to repeat the mistake.
>
> There is no imaginable use to have wrap-around instead (except that you get a wrong, but the same behavior between different compilers). But no use for wrap-around specifically. You could as well have a result of 0.
That’s an argument for giving defined trapping behavior, not UB.
> But the error is not caught either with wrap-around behavior, whereas with UB the compiler may at least give an error, if it detects it at compile-time.
This is a misunderstanding of what UB means.
The compiler does not prove that your program has invoked UB, it simply assumes that the UB cannot happen.
You are arguing “I believe this is an error, and therefore we should make even more errors possible”. For example back when compilers silently changed a pile of secure code into exploitable code: developers wrote `if (a + b < a) { .. }` the _only_ reason this is “incorrect” is the language defining it as incorrect, the only reason it became exploitable is that the specification says the behavior that is well defined and deterministic everywhere, is incorrect, and in the early to mid 2000s compilers started applying this to overflow..
There is no reason to keep doing that. Repeating “this code is wrong because we have said it is wrong” is not a valid counter argument: the only reason it is wrong is *because* we have said it is.
—Oliver
Your core argument is “signed overflow is always an error/bug”.
Declaring “signed overflow is UB” does not support that point of view.
The correct way to say “signed overflow is an error” is to say “signed overflow is erroneous behavior”. That makes it explicit that the overflow is an error, and it permits developers to rely on consistent and deterministic behavior, rather than dealing with an adversarial compiler that is blindly assuming that it cannot happen.
> On Sep 3, 2025, at 1:13 PM, Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> If something is UB in the standard, the implementations can define it to be something specific instead. That is standards compliant and not a new dialect, as long as the code does not depend on that outcome.
Yes, but the code is wrong even if it is correct under your specific dialect. You cannot say “I am relying on this specific behavior” and then say “I am writing C++”, because your “correct” code is incorrect per standard C++, another compiler results in your code invoking UB.
> > Because of that code that is correct with that flag, is not correct C++
> But that is the point of it. Signed overflow has not correct inputs. The preconditions are wrong. An implementation (and its flags) can choose, what happens under those circumstance.
I know that C++ says there is no correct input. Literally the entire point of what I have been saying, is that the only reason you are able to say "Signed overflow has not correct inputs” is because the specification has defined it that way. That’s a tautological argument, “this is undefined because we have said it is undefined”. I am saying “we should not be saying well defined behavior is undefined behaviour”.
> That is similar as if you have a contract violation for the contracts feature.
Yes, and I argued strongly for contract violations to be an error.
> A program error was detected and it can be configured, what happens in that case.
I’m not sure if you’re talking about contracts (with their own issues w.r.t permitting UB) or overflow UB where the entire point is that the overflow is not being detected, the compiler is just pretending it cannot happen.
> The program is not correct in the first place, if it comes to such an error.
Again, the program is only wrong because we have said it is wrong. You are saying we should continue to repeat choices made in the past that are demonstrably bad for program safety, Even though there is literally no reason to repeat the mistake.
>
> There is no imaginable use to have wrap-around instead (except that you get a wrong, but the same behavior between different compilers). But no use for wrap-around specifically. You could as well have a result of 0.
That’s an argument for giving defined trapping behavior, not UB.
> But the error is not caught either with wrap-around behavior, whereas with UB the compiler may at least give an error, if it detects it at compile-time.
This is a misunderstanding of what UB means.
The compiler does not prove that your program has invoked UB, it simply assumes that the UB cannot happen.
You are arguing “I believe this is an error, and therefore we should make even more errors possible”. For example back when compilers silently changed a pile of secure code into exploitable code: developers wrote `if (a + b < a) { .. }` the _only_ reason this is “incorrect” is the language defining it as incorrect, the only reason it became exploitable is that the specification says the behavior that is well defined and deterministic everywhere, is incorrect, and in the early to mid 2000s compilers started applying this to overflow..
There is no reason to keep doing that. Repeating “this code is wrong because we have said it is wrong” is not a valid counter argument: the only reason it is wrong is *because* we have said it is.
—Oliver
Received on 2025-09-03 21:08:04