Date: Fri, 05 Sep 2025 09:34:53 +0100
On 5 September 2025 08:57:30 BST, David Brown via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>
>On 04/09/2025 19:22, Oliver Hunt wrote:
>> 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?
>>
>
>It seems I have seriously misunderstood the C++26 term "erroneous behaviour" from something else I had read.
>
>I am still somewhat confused that behaviour can be "well-defined" and also "if the execution contains an operation specified as having erroneous behaviour, the implementation is permitted to issue a diagnostic and is permitted to terminate the execution at an unspecified time after the operation".
>
>Presumably if signed integer overflow were to be deemed "erroneous behaviour", it would then have to have defined behaviour (wrapping being the obvious choice)
Unspecified result would be another choice, which would allow some (but not all) of current optimizations without making the behavior of the whole process undefined.
>, but toolchains would be allowed to have traps or halt with a diagnostic if an execution has an overflow (in the manner of gcc/clang sanitizers) ?
Correct. Or with -ftrapv.
>
>
>On 04/09/2025 19:22, Oliver Hunt wrote:
>> 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?
>>
>
>It seems I have seriously misunderstood the C++26 term "erroneous behaviour" from something else I had read.
>
>I am still somewhat confused that behaviour can be "well-defined" and also "if the execution contains an operation specified as having erroneous behaviour, the implementation is permitted to issue a diagnostic and is permitted to terminate the execution at an unspecified time after the operation".
>
>Presumably if signed integer overflow were to be deemed "erroneous behaviour", it would then have to have defined behaviour (wrapping being the obvious choice)
Unspecified result would be another choice, which would allow some (but not all) of current optimizations without making the behavior of the whole process undefined.
>, but toolchains would be allowed to have traps or halt with a diagnostic if an execution has an overflow (in the manner of gcc/clang sanitizers) ?
Correct. Or with -ftrapv.
Received on 2025-09-05 08:35:05