JavaScript array problem affecting bugzilla

[John Sullivan]

Thanks for the additional comments . I agree that there is a lot more 
bulletproofing against bad values that could be done anywhere we use 
doubles even temporarily. We might take a pass at that, but it probably 
won't be high on our list of priorities until/unless we see it start to 
affect real-world sites.

John

On Jul 19, 2004, at 5:13 PM, Harri Porten wrote:

> On Mon, 19 Jul 2004, John Sullivan wrote:
>
>> This line:
>>
>> double begin = args[0].toInteger(exec);
>>
>> was setting begin to a value reported by the debugger as
>> nan(0x8000000000000). This failed both the (begin < 0) check and the
>> (begin > length) check, because NAN values fail all comparisons. 
>> Later,
>> this line:
>
> Ah! As we still do pure int arithmetic in this function this never was 
> an
> issue.
>
>>> What happens when the user specifies NaN explicitly?
>>
>> Good point. The UndefinedType check on args[0] wouldn't catch that.
>> I've added additional bulletproofing for this in this new patch:
>
> OK. Not needed here but in case we change toInteger() to return double 
> one
> day, too, it will be of course.
>
> Couldn't you just do the cast to int right away? Or did you want to do 
> the
> range checks with floating point numbers for a specific reason? I'm 
> asking
> because I personally don't know what kind of behaviour
>
>   double -> int
>
> casts have over the complete double range. Do they have a continuous 
> and
> linear behaviour? Hmm. Probably not:
>
>   double d = 3000000000.0; // > MAX_INT
>   int i = static_cast<int>(d);
>
> i is -2147483648. So someone (stupid) could still trigger a nasty loop 
> by
> passing very large numbers.
>
> Harri.
>
> _______________________________________________
> Khtml-devel at kde.org
> https://mail.kde.org/mailman/listinfo/khtml-devel