Re: Conversion of ES Number to WebIDL long long and unsigned long long should not throw by default

On 2/13/12 2:16 PM, Allen Wirfs-Brock wrote:
>
> On Feb 13, 2012, at 5:12 AM, Boris Zbarsky wrote:
>
>> On 2/13/12 3:34 AM, Sigbjorn Finne wrote:
>>> On Wed, Feb 8, 2012 at 5:28 AM, Boris Zbarsky<bzbarsky@mit.edu
>>> <mailto:bzbarsky@mit.edu>>  wrote:
>>>
>>>     The current WebIDL algorithm for long long says:
>>>
>>>     Set x to sign(x) * floor(abs(x)).
>>>     Set x to x modulo 2^64.
>>>     If x is greater than or equal to 2^63, then set x to x − 2^64.
>>>     If x<  −(2^53 − 1) or x>  2^53 − 1, then throw a TypeError.
>>>
>>>     This makes no sense. The justification is something about how your x
>>>     might have lost precision and so you may not be hitting the 64-bit
>>>     int you "wanted"... but in that case the check-and-throw should be
>>>     done before reduction mod 2^64. Doing it after just means the result
>>>     is somewhat random once your double is greater than 2^64.
>>>
>>> The purpose of the third step is to adjust sign, I'd say.
>>
>> Yes, of course.  My point was that doing the fourth step after the second step is nonsensical.
>
> I agree, if you want that check it needs to be after step 2.

I'd think before step 2, if done at all.  And then it's just like the 
[EnforceRange] variant, I think, so spec authors can already ask for it 
explicitly.

> But I think there may be more fundamental issues here. Does it really make sense to do mod 2^64 value wrap-around for values>2^64.

An excellent question, yes.

> Line 45 is intended to throw on integer that are possibly imprecise (low order bits rounded) values in the range 2^53..2^64-1.  However, line 2 means that every value of x is possibly imprecise because of rounding in that step.

Yep.

> It would seem that you either shouldn't do the wrap-around or you shouldn't throw on possibly imprecise values.

Totally agreed.  I think this whole throwing should just go away; people 
who want that behavior can already [EnforceRange].

-Boris

Received on Monday, 13 February 2012 19:26:35 UTC