On Thu, Sep 4, 2025 at 7:35 AM David Brown via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On 04/09/2025 07:48, Peter C++ via Std-Proposals wrote:
> > FWIW
> >
> > one can implement efficient non-UB integer replacement types, eg, for
> > safety critical systems using enum class types as representation.
> >
> > see for example: https://github.com/PeterSommerlad/PSsimplesafeint
> > <https://github.com/PeterSommerlad/PSsimplesafeint>
> >
> > Regards
> > Peter
> >
>
> You can indeed make such classes - and give them dangerously misleading
> names like "Simple Safe Int".
>
> It is fine to implement wrapping signed integer classes if that's what
> you want - it is /not/ fine to pretend they are somehow safe or suitable
> for safety-critical systems. It doesn't matter if your overflows wrap -
> if you have an overflow, your safety-critical system is screwed.
>
> (Some other aspects of your library /are/ positive for safety, such as
> disallowing mixed signed operations and limiting certain other
> operations. It's only the overflow behaviour I am in strong
> disagreement about.)
>
>
> You'd be a lot better off with :
>
> using SignificantlySaferIntType = int64_t;
>
> That would eliminate the vast majority of signed integer overflow bugs,
> and give the /correct/ answer to 32-bit overflows.
>
> And anyone writing new code with enough care about overflow and code
> correctness that they might consider something beyond just using "int",
> will already be able to handle overflow in various ways - such as
> sanitizing values before calculations ("look before you leap", rather
> than trying to find a way to recover from jumping off a cliff and
> somehow ending up miles in the air). The checked arithmetic functions
> in C++26 are another option.
>
>
>
>
> I am in favour of integer class libraries that handle overflow in
> different ways. But the naming should be based on what is actually done
> - undefined behaviour, wrapping, zeroing, throwing, trapping, calling
> terminate/abort/whatever, saturating, returning an unspecified but valid
> value, setting errno, etc.
>
>
> I am not in favour of pretending or implying that the use of a
> particular integer class makes the code "safe" (or even just "safer").
>

I think that actually, wrapping behaviour is safe*r* than UB, saturating
behaviour, or producing an unspecified value. I won't claim that it's
completely safe.

Why? Because it's the choice that doesn't result in information loss when
overflow occurs. In particular, for example, in an expression of the form
`a + b - c`, if `a + b` overflows but the final result fits in the type,
you will actually get the correct result if the type is specified to wrap.


>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
*Brian Bi*