archives

« Bugzilla Issues Index

#145 — eliminate uint32 length restriction the the length of array objects.


see discussion in thread around https://mail.mozilla.org/pipermail/es-discuss/2011-July/015975.html

...Eliminating the range error and the Uint32 restriction on the association between array indexed properties and the "length" property. Instead replace it with a ToInteger constraint. This is essentially how string operations are defined. Implementations could still optimize for lengths <2^32 and or any other size they deemed appropriate.


Also, the max length value should probably be limited to the largest precise IEEE double precision integer. Exceeding that should be a RangeError.


The ES5 spec already violates its own invariant on array lengths. Consider this example:

var a = []
a[0xffffffff] = 1

According to ES5.1 15.4.5.1 ([[DefineOwnProperty]] for arrays), step 4.e.i does not reject overflow of index+1, so step 4.e.ii should actually set 'length' to the value 0x100000000, which is not a uint32. Both V8 and FF actually wrap around and set a.length to 0 in this case (which doesn't make a hell lot of sense either). Instead, the assignment should be rejected.

Unfortunately, the problem won't go away by pushing the boundary to 2^53. The maximum allowed index has to be one less then the maximum allowed length either way.


ES5.1 does not violate the invariant, step 4 of 15.4.5.1 is only used for array indices which means keys in [0, 0xffffffff[ , cf. introductory paragraph in 15.4.


Ah, you are right, thanks! I indeed missed the bit about an index not being equal to 2^32-1 in the intro.


Just ran into a case where 2^32 size is checked in rev32:

9.4.2.2 ArrayCreate(length, proto) Abstract Operation

3. If length>2^32-1, throw a RangeError exception.


(In reply to Chris Toshok from comment #5)
> Just ran into a case where 2^32 size is checked in rev32:
>
> 9.4.2.2 ArrayCreate(length, proto) Abstract Operation
>
> 3. If length>2^32-1, throw a RangeError exception.

I'm not sure what you are trying to say here. Are you saying that you found code real world JS code that this check is breaking?

(BTW, this is a ES5.x ticket, if you think there is an ES6 problem you should probably open a new ticket)


Ah, sorry about adding it to an es5 issue. I didn't notice when it came up as a possible duplicate when I was entering a bug for 9.4.2.2.


we didn't have this change in ES6