When expecting a positive integer...

Mark S. Miller erights at google.com
Tue Apr 9 07:09:27 PDT 2013


Consider instead the Nat operation at <
https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/startSES.js#412
>:

var MAX_NAT = Math.pow(2, 53);
  function Nat(allegedNum) {
    if (typeof allegedNum !== 'number') {
      throw new RangeError('not a number');
    }
    if (allegedNum !== allegedNum) { throw new RangeError('NaN not natural'
); }
    if (allegedNum < 0)            { throw new RangeError('negative'); }
    if (allegedNum % 1 !== 0)      { throw new RangeError('not integral'); }
    if (allegedNum > MAX_NAT)      { throw new RangeError('too big'); }
    return allegedNum;
  } This returns allegedNum only if it is a non-negative integer within the
range of *consecutively* representable non-negative integers. For what uses
of ToPositiveInteger would Nat not be better? Btw, given the spec at <
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-9.1.11>
ToPositiveInteger is badly misnamed. +0 is not a positive integer. It is a
non-negative integer. +Infinity is not an integer. -Infinity is neither
positive nor an integer.


On Tue, Apr 9, 2013 at 7:01 AM, Kevin Gadd <kevin.gadd at gmail.com> wrote:

> I previously had a discussion with someone about Typed Array sizes in
> particular - at present it seems like no existing implementation of Typed
> Arrays will allow you to allocate one larger than 2GB, regardless of the
> actual numeric types being used. But when I did a quick scan of the Safari,
> Chrome and Spidermonkey implementations, I found some uses of ToInt32 and
> equivalent operations instead of ToUInt32 - which would imply being limited
> to a maximum index that fits into a positive 32-bit integer.
>
> Being able to allocate a 4GB typed array on a 64-bit machine, if not one
> even bigger than that, would certainly be welcome.
>
>
> On Tue, Apr 9, 2013 at 6:58 AM, Brendan Eich <brendan at mozilla.com> wrote:
>
>> Dmitry Lomov wrote:
>>
>>> If people agree this is generally a thing to be avoided, I am happy to
>>> collect a systematic list of these issues and suggest fixes - but maybe I
>>> am missing something and that has some deep motivation?
>>>
>>
>> No, please collect and file at bugs.ecmascript.org -- these are indeed
>> errors in the draft. We need to throw on negative length. We must *not*
>> spec clamping negative indexes to 0 at runtime. Other deviations from
>> Khronos and implementation need to be considered carefully in light of
>> performance and safety (which are not always at odds).
>>
>> Thanks to you and Domenic for flagging.
>>
>> /be
>>
>> ______________________________**_________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>
>
>
>
> --
> -kg
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130409/078b181c/attachment.html>


More information about the es-discuss mailing list