Re: Enforcing (unsigned) long long ranges

Sigbjorn, could you please file a WebIDL bug? Thanks.


On Wed, Jan 8, 2014 at 8:24 AM, Mark S. Miller <erights@google.com> wrote:

> Good catch. Yes, WebIDL apparently made the same mistake we had made at
> first, not realizing why we need the narrower range. It should be changed
> for the same reason we changed it in ES6.
>
> For those who missed the earlier discussion, the "desirable properties
> wrt equational reasoning" that Sigbjorn refers to are, for example:
>
> var c = a + b;
> if (isSafeInteger(a) && isSafeInteger(b) && isSafeInteger(c)) {
>   // c represents the accurate sum of a and b
> }
>
> With the wider range, this guarantee is lost.
>
>
>
> On Tue, Jan 7, 2014 at 11:44 PM, Sigbjorn Finne <sof@opera.com> wrote:
>
>> Hi,
>>
>> currently, the ES binding for WebIDL uses the range of exactly
>> representable integers [-2^53, 2^53] (*)
>>
>>   http://heycam.github.io/webidl/#es-long-long
>>   http://heycam.github.io/webidl/#es-unsigned-long-long
>>
>> ES6 will provide support for testing the range of unambiguously
>> representable integers [-2^53 + 1, 2^53 - 1]
>>
>>
>> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-
>> number.issafeinteger
>>
>> a range with desirable properties wrt equational reasoning.
>>
>> So, with the above, if you have an attribute like
>>
>>   [EnforceRange] attribute long long tvisyn;
>>
>> an implementation of the ES binding will enforce the WebIDL "long long"
>> range, but ES(6) code will have to perform a second check of the range if
>> concerned about restricting this to the safe range.
>>
>> How about aligning the WebIDL IDL range with ES6 & unambiguously
>> representable integers?
>>
>> (Apologies if this has been resolved already or there's an open issue on
>> it; couldn't find any.)
>>
>> --sigbjorn
>>
>> * - a fairly recent change,
>>
>>
>> http://dev.w3.org/cvsweb/2006/webapi/WebIDL/v1.xml.diff?r1=
>> 1.74;r2=1.75;f=h
>>
>> (it was the "safe" range prior to that.)
>>
>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>



-- 
    Cheers,
    --MarkM

Received on Wednesday, 8 January 2014 16:26:01 UTC