Re: commit (head): fix 7011

Thanks Martin,

I will go throught the revisions code and replace the 0xffffffff with
UINT_MAX; that should be both portable and safe.

Tomas

>
> 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 09:55:21 2004