Signed word lengths and indexes

["Jérôme M. Berger"]

Andrei Alexandrescu wrote:
> 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 value~@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 of~@val at .
> ==============
> 
> (This heavily adorned text also shows what sausage making looks like...)
> 
	In the original code, the problem didn't come from an unary minus.
The rhs expression was quite a bit more complicated than that (not
counting the fact that it was hidden in a preprocessor macro...).

	Note moreover that the problem doesn't come from the unary minus
since the code works as expected on 32-bit platforms...

		Jerome
-- 
mailto:jeberger at free.fr
http://jeberger.free.fr
Jabber: jeberger at jabber.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20100616/c461452d/attachment.pgp>