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 <

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

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