Jérôme M. Berger wrote:
Jérôme M. Berger wrote:
Walter Bright wrote:
Jérôme M. Berger wrote:
Actually, that problem already occurs in C. I've had problems when
porting code from x86 to x86_64 because some unsigned operations
don't behave the same way on both...
How so? I thought most 64 bit C compilers were specifically designed to
avoid this problem.
I can't isolate it to a minimal test case, but at my job, we make
an image processing library. Since negative image dimensions don't
make sense, we decided to define width and height as "unsigned int".
Now, we have code that works fine on 32-bit platforms (x86 and arm)
but segfaults on x86_64. Simply adding an (int) cast in front of the
image dimensions in a couple of places fixes the issue (tested with
various versions of gcc on linux and windows).
Gotcha! See the attached test case. I will post the explanation for
the issue as a reply to give everyone a chance to try and spot the
error...
Jerome
Whoa! That's indeed unfortunate. Allow me some more whoring for TDPL:
==============
\indexes{surprising behavior!of unary \lstinline{-}}%
One surprising behavior of unary minus is that, when applied to an
unsigned value, it still yields an unsigned value (according to the
rules in~\S~\vref{sec:typing-of-ops}). For example,\sbs @-55u@ is\sbs
@4_294_967_241@, which is\sbs \ccbox{uint.max - 55 + 1}.
\indexes{unsigned type, natural number, two's complement, overflow}%
The fact that unsigned types are not really natural numbers is a fact
of life. In\sbs\dee and many other languages, two's complement
arithmetic with its simple overflow rules is an inescapable reality
that cannot be abstracted away. One way to think \mbox{of} @-val@ for
any integral val...@val@ is to consider it a short form \mbox{of}$\,$
\cc{\~val + 1}; in other words, flip every bit in @val@ and then add
@1@ to the result. This manipulation does not raise particular
questions about the signedness o...@val@.
==============
(This heavily adorned text also shows what sausage making looks like...)
Andrei
