Sigh. Early send.


>> 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.
>
> What do you mean by "erroneous behaviour" ? What do you think the C++ standards mean by that term (define in C++26) ? Why do you think it is in any way better than "undefined behaviour" for signed integer overflow?

I mean exactly what the standard says.

>
> The point of the new concept of "erroneous behaviour" in C++26 is to strongly encourage (but not force) compilers to give warnings during compile time for some diagnosable errors (such as reading local variables before they are initialised or assigned), and to make it acceptable for conforming compilers to add run-time checks that halt with an error message some time after hitting "erroneous behaviour”.
> It does not actually make this a requirement - in effect, AFAIUI, "erroneous behaviour" means basically the same as "undefined behaviour" except that compilers are strongly encouraged to help developers see such issues at compile time and/or runtime in debug or sanitising modes.

I do not understand how you can possibly think that. Here is the literal definition of EB:

"well-defined behavior that the implementation is recommended to diagnose”

How do you get “the same as ub” from a definition that explicitly states that the behavior is well defined?

—Oliver