JavaScript array problem affecting bugzilla

[Harri Porten]

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.