KJS::SimpleNumber on 64 bit machines

[Maciej Stachowiak]

On Oct 1, 2003, at 10:17 AM, Harri Porten wrote:

> Hi,
>
> the SimpleNumber::fits() trickery causes problems on 64 bit machines. 
> At
> least on Alphas. I can reproduce a SIGFPE that happens when NaN is
> passed. gcc is suspicous about the comparisons:

Is this a problem for all 64-bit architectures, or just Alphas and 
their particular handling of signalling NaNs? Where exactly does the 
NaN come from? SimpleNumber shouldn't be able to hold a NaN, and should 
not return a NaN.

>
> simple_number.h: In static member function `static bool
>    KJS::SimpleNumber::is(const KJS::ValueImp*)':
> simple_number.h:39: warning: cast from pointer to integer of different
> size
> simple_number.h: In static member function `static int
>    KJS::SimpleNumber::value(const KJS::ValueImp*)':
> simple_number.h:40: warning: cast from pointer to integer of different
> size
> simple_number.h:40: warning: cast from pointer to integer of different
> size
> simple_number.h: In static member function `static KJS::ValueImp*
>    KJS::SimpleNumber::make(int)':
> simple_number.h:48: warning: cast to pointer from integer of different
> size

I'd definitely like to get rid of the warnings, though. Maybe it would 
be better to use long, or intptr_t, and pick the masks and such based 
on sizeof(long)?

>
> I have a workaround that simply avoids letting NaN to slip through:
>
> diff value.cpp.bak value.cpp
> 339c339
> <
> : Value(SimpleNumber::fits(d) ? SimpleNumber::make((long)d) : 
> (KJS::isNaN(d) ? NumberImp::staticNaN
> : new NumberImp(d))) { }
> ---
>>  : Value(KJS::isNaN(d) ? NumberImp::staticNaN
> : (SimpleNumber::fits(d) ? SimpleNumber::make((long)d) : new
> NumberImp(d))) { }
>
> But this is probably less efficient because of the different ordering.

So the fits check gets SIGFPE? It really sounds like you must be in 
"signalling NaN" mode, since comparisons against NaN should just return 
false otherwise, and not get SIGFPE.

> Anybody (maybe from Apple) could provide a suggestion or patch on how 
> to
> clean up this issue ? Any experiences from 64-bit Macs ?

I really think this is a signalling NaN issue, not a 64-bit issue, but 
I don't have access to either an Alpha or a 64-bit Mac.

  - Maciej