W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2012

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 13 Feb 2012 14:26:05 -0500
Message-ID: <4F3963CD.8060408@mit.edu>
To: Allen Wirfs-Brock <allen@wirfs-brock.com>
CC: Sigbjorn Finne <sigbjorn.finne@gmail.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
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 

> 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.


> 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].

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:05 UTC