Portability of uint over/underflow behavior

[Don]

bearophile wrote:
> Don:
>> The question was about incrementing uint, not int. Preventing wraparound 
>> on uints would break everything!
> 
> If optional runtime overflow controls are added to integral values, then they are performed on ubyte/ushort/uint/ulong/ucent too, because leaving a hole in that safety net is very bad and useless.

But uints HAVE no overflow! In the case of an int, you are approximating 
a mathematical infinite-precision integer. An overflow means you went 
outside the available precision.
A uint is quite different.
uint arithmetic is perfectly standard modulo 2^32 arithmetic.
Don't be confused by the fact that many people use them as 
approximations to infinite-precision positive integers. That's _not_ 
what they are.

Consider for example machine addresses on a 32-bit address bus.
Given pointers p and q,
p + q - p is perfectly well defined, and is always equal to q.
It makes no difference whether p is greater than or less than q.
q-p is definitely not an int. (q could be uint.max, and p could be 0).
Likewise, p+1 is always defined, even if p is uint.max (p+1 will then be 0).


> In modules where you need wraparounds, you can tell the compiler to disable such controls (recently I have suggested a syntax that works locally: safe(...) {...}, but Walter seems to prefer a module-level syntax for this).


> 
> Bye,
> bearophile