unsigned interger overflow

[monarch_dodra]

On Wednesday, 2 October 2013 at 08:51:43 UTC, qznc wrote:
> On Wednesday, 2 October 2013 at 05:41:50 UTC, Jonathan M Davis 
> wrote:
>> On Wednesday, October 02, 2013 12:32:24 Alexandr Druzhinin 
>> wrote:
>>> Is it safe to replace code:
>>> 
>>> uint index;
>>> // do something
>>> index++;
>>> if(index == index.max)
>>> index = index.init;
>>> 
>>> by the following code
>>> uint index;
>>> // do something
>>> index++; /// I use unsigned int so uint.max changed to 0 
>>> automagically
>>
>> Well, not quite. Your first one skips uint.max. It goes from 
>> uint.max - 1 to 0,
>> whereas the second one goes from uint.max to 0. So, they're 
>> subtly different.
>> But yes, incrementing the maximum value of an unsigned 
>> integral type is
>> guaranteed to wrap around to 0. Signed integers are of course 
>> another matter
>> entirely, but it's guaranteed to work with unsigned integers.
>
> For signed integers there seems to be no clear consensus [0], 
> although personally I would read the spec [1] as wrapping 
> happens for int as well:
>
> "If both operands are of integral types and an overflow or 
> underflow occurs in the computation, wrapping will happen."
>
> I also consider it reasonable, since every architecture uses 
> 2s-complement.
>
> [0] http://forum.dlang.org/thread/jo2c0a$31hh$1@digitalmars.com
> [1] http://dlang.org/expression.html

I re-read the thread. AFAIK, C++ makes no promises for signed 
overflow/underflow, because it targets both 1's complement and 
2's complement architecture, where the behavior of *flow differs 
for signed types.

Last time I read TDPL, I *seem* to remember that it stated that D 
targeted *exclusively* 2's complement architechture. So I'd 
conclude that, even if it is not *specified*, the only logical 
behavior for signed under/over flow, is to jump from from .min to 
.max