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 <[email protected]> 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 <[email protected]> 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
>> [email protected]
>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>
>
>
>
> --
> -kg
>
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
