<p dir="ltr"><br>
On 19 Oct 2014 09:40, "monarch_dodra via Digitalmars-d" <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br>
><br>
> On Saturday, 18 October 2014 at 23:10:15 UTC, Ola Fosheim Grøstad wrote:<br>
>><br>
>> On Saturday, 18 October 2014 at 08:22:25 UTC, monarch_dodra wrote:<br>
>>><br>
>>> Besides, the code uses x + 1, so the code is already in undefined state. It's just as wrong as the "horrible code with UB" we wère trying to avoid in the first place.<br>
>>><br>
>>> So much for convincing me that it's a good idea...<br>
>><br>
>><br>
>> Not sure if you are saying that modulo-arithmetic as a default is a bad or good idea?<br>
><br>
><br>
> Op usually suggested that all overflows should be undefined behavior, and that you could "pre-emptivelly" check for overflow with the above code. The code provided itself overflowed, so was also undefined.<br>
><br>
> What I'm pointing out is that working with undefined behavior overflow is exceptionally difficult, see later.<br>
><br>
><br>
>> In D and (C++ for uint) it is modulo-arithmetic so it is defined as a circular type with at discontinuity which makes reasoning about integers harder.<br>
><br>
><br>
> What interesting is that overflow is only defined for unsigned integers. signed integer overflow is *undefined*, and GCC *will* optimize away any conditions that rely on it.<br>
></p>
<p dir="ltr">Good thing that overflow is strictly defined in D then. You can rely on overflowing to occur rather than be optimised away.</p>
<p dir="ltr">Iain.</p>