Re: commit (head): fix 7011

From: Martin Sevior <msevior_at_physics.unimelb.edu.au>
Date: Tue Aug 17 2004 - 09:44:49 CEST

On Tue, 2004-08-17 at 16:42, Tomas Frydrych wrote:
> Hi MG,
>
> > You also added still more 0xffffffff usage which, in some cases (I don't
> > know about that particular rtf importer code), can be quite corruptive
> > on 64-bit platforms, causing a lot of the crashes like I'm seeing on my
> > 64-bit box where gdb tells me I segfaulted and, surprise surprise,
> > someParam=4294967295.
>
> I assume that you are referring to problems with 0xffffffff used in
> place of -1; the revision level is, however, an unsigned int, so the
> value is the same irrespective of the int size. Or am I missing
> something?
>

Hi Tomas,
         It's an issue of robustness with 64-bitness. If you do
arithmetic with mixed sign variables (or even subtractions) in a 64-bit
environment, the value of 0xfffffff is ambiguous. If the compiler
internally does 64-bit calculations should 0xfffffff be sign extended to
-1 (0xffffffffffffff) or left truncated as 0x00000000fffffff?

I've been busily taking 0xfffffff's out of the code and putting
UT_sint32 in as many places as possible to remove these ambiguities.

In a perfect world the compilers would always get this right, but mg and
I have seen the following happen with a 64-bit build.

UT_uint32 x = 35
UT_uint32 y = 17
UT_uint32 z = 24

UT_uint32 w = y - z + x

result is..

w = 4294967253

rather than the correct

w = 42

Which we got on a 32-bit build.

Cheers

Martin

> Tomas
>
>
Received on Tue Aug 17 08:47:44 2004

This archive was generated by hypermail 2.1.8 : Tue Aug 17 2004 - 08:47:44 CEST