> On Dec 11, 2024, at 9:41 AM, Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
>
>> That's incorrect. Signed integers do absolutely overflow (and underflow), by
>> design constraints alone it can't represent as many positive values as an
>> unsigned integer of the same size. What it means is when it does overflow
>> it's UB.
>
> The point is that, being UB, the compiler is allowed to assume it *didn't*
> overflow. So long as your code is correct and it really didn't, there's a minor
> but real performance gain in not having code emitted to deal with an allowed
> overflow.

To be sure UB allows the compiler to do all sorts of things. The introduction of optimizations based on UB for overflow caused a lot of security vulnerabilities, the canonical

If (x + y < x) abort()

removals that started turning previously “correct” code to gain exploitable security failures.

I’m not sure - because UB around these conversions is always obnoxious :D - but I _think_ that a compiler could see

signed x = some_unsigned;
...
If (x < 0 || x > size) abort()

And remove the x<0 because I think x<0 would require the unsigned->signed conversion to be UB

The core problem is that if your code triggers UB, it is definitionally *not* correct (Cue Oliver complaining about overuse of UB :D)

—Oliver

>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel DCAI Platform & System Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals