Portability of uint over/underflow behavior

[dsimcha]

== Quote from Nick Sabalausky (a at a.a)'s article
> "Don" <nospam at nospam.com> wrote in message
> news:gjsnf2$26g4$1 at digitalmars.com...
> > 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.
> >
> A uint is an int with the domain of possible values shifted by +uint.max/2
> (while retaining binary compatibility with the overlapping values, of
> course). Modulo 2^32 arithmetic is just one possible use for them. For other
> uses, detecting overflow can be useful.

Mostly, I was thinking that relying on this behavior wouldn't work if some DS9K
architecture used a signed int representation other than two's complement or used
saturation arithmetic.  Am I wrong here, too?