czw., 4 wrz 2025 o 08:32 David Brown <david.brown_at_[hidden]> napisał(a):
>
>
>
> On 03/09/2025 21:09, Oliver Hunt wrote:
> >
> >
> >> On Sep 3, 2025, at 4:53 AM, David Brown <david.brown_at_[hidden]> wrote:
> >>>>
> >>>> Do we /need/ UB on signed arithmetic overflow? No. Do we /want/ UB
> >>>> on signed arithmetic overflow? Yes, IMHO. I am of the opinion that
> >>>> it makes no sense to add two negative numbers and end up with a
> >>>> positive number. There are very, very few situations where wrapping
> >>>> behaviour on signed integer arithmetic is helpful - making it
> >>>> defined as wrapping is simply saying that the language will pick a
> >>>> nonsensical result that can lead to bugs and confusion, limit
> >>>> optimisations and debugging, and cannot possibly give you a
> >>>> mathematically correct answer, all in the name of claiming to avoid
> >>>> undefined behaviour.
> >>> This as argument for unspecified or implementation defined behavior,
> >>> not introducing a brand new type, with *all* of the known security
> >>> issues of `int` (that we decided were not necessary for the
> >>> performance of unsigned integers).
> >>
> >> "int" does not, in itself, have "security issues". Incorrect
> >> programming can have security implications. Overflow - whether
> >> wrapping or UB, or anything else - is usually a bug in the code.
> >> Giving a fixed definition to the incorrect value does not magically
> >> fix the error in the code.
> >
> > No, Any new feature that introduces UB for no reason is a security
> > feature, for the same reason that creating new types that introduce
> > lifetime issues when used in a trivially obvious way (think: returning a
> > string_view).
> >
>
> Those are two wildly different things.
>
> Undefined behaviour is not in itself a security risk. /Incorrect/
> behaviour is a security risk. It does not matter whether a program bug
> has undefined behaviour, or defined and documented behaviour that is
> different from expected. If a program hits a bug in the code, it is now
> no longer doing what the programmer intended and predicted - and /that/
> is a security risk (for code that is relevant for security).
>
> It does not matter if "a + b" overflows and has undefined behaviour, or
> if "a + b" overflows and has defined but unexpected behaviour, such as
> suddenly jumping in value.
>

To be devil's advocate, UB is worse as it is "viral", you not only get
the wrong value but
compiler can do unexpected things, like remove `if` that program tries
to use to detect overflow.
This is why standart try to move to Erroneous Behavior in many cases.

One thing for overflows to be "illegal" is that the program is
portable to other sizes of `int`.
Same program that works with `int` that has size of 16bit and does not
have UB, it will work
on machines that have 64bit int.


Could it be better to use Erroneous Behavior behavior here too?
And exactly what happens to be implementation defined?