Date: Fri, 5 Sep 2025 13:29:30 +0200
On 05/09/2025 10:34, Lénárd Szolnoki wrote:
>
>
> 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.
>
Making the result "unspecified" could, I agree, allow some flexibility
for the compiler to optimise. But it would not allow many of them. For
example, in a loop with "x[++i]" where "x" is a pointer or array and "i"
is an int, with UB the implementation can assume "++i" never overflows
and just use a single pointer which it increments without worrying about
"++i" wrapping back to 0. If "++i" gave an unspecified value on
overflow, the compiler could not make the same assumptions - if there
were an overflow, and the pointer was then at the next element beyond
x[INT_MAX], it would imply "i" had the value of INT_MAX + 1. That is
not a valid possibility for an unspecified value - if I have understood
things correctly, "i" would have to contain a valid int value, without
any requirements about /which/ value it has.
Where "unspecified results" would really shine is if you have a looped
calculation and an independent way of checking for validity of the
calculation as a whole. For example, if you are summing an array
(especially with SIMD or other vector processing), you don't want to be
checking for overflow for each element if the data is not valid. But
you also don't want to risk executing UB by trying to add values without
knowing their validity. If the overflow gives unspecified results, you
know you can't get correct results, but you are not doing anything unsafe.
>> , 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.
Yes.
As I understand it, "-ftrapv" is not considered as accurate as
"-fsantize=signed-integer-overflow", and the later is preferred for
modern versions of gcc. But "-ftrapv" is another such option.
>
>
> 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.
>
Making the result "unspecified" could, I agree, allow some flexibility
for the compiler to optimise. But it would not allow many of them. For
example, in a loop with "x[++i]" where "x" is a pointer or array and "i"
is an int, with UB the implementation can assume "++i" never overflows
and just use a single pointer which it increments without worrying about
"++i" wrapping back to 0. If "++i" gave an unspecified value on
overflow, the compiler could not make the same assumptions - if there
were an overflow, and the pointer was then at the next element beyond
x[INT_MAX], it would imply "i" had the value of INT_MAX + 1. That is
not a valid possibility for an unspecified value - if I have understood
things correctly, "i" would have to contain a valid int value, without
any requirements about /which/ value it has.
Where "unspecified results" would really shine is if you have a looped
calculation and an independent way of checking for validity of the
calculation as a whole. For example, if you are summing an array
(especially with SIMD or other vector processing), you don't want to be
checking for overflow for each element if the data is not valid. But
you also don't want to risk executing UB by trying to add values without
knowing their validity. If the overflow gives unspecified results, you
know you can't get correct results, but you are not doing anything unsafe.
>> , 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.
Yes.
As I understand it, "-ftrapv" is not considered as accurate as
"-fsantize=signed-integer-overflow", and the later is preferred for
modern versions of gcc. But "-ftrapv" is another such option.
Received on 2025-09-05 11:29:39