Array lengthening methods applied to maximally long arrays
Here's what I observed:
Opera 9.63 - conforms to ES3/ES5 spec. Range error on a.push(1) after creating a non-array index property named "4294967295" and leaving length as 4294967295 Chrome 1.0.154.65 conforms to ES3/ES5 spec. Range error on a.push(1) after creating a non-array index property named "4294967295" and leaving length as 4294967295
Firefox 3.0.8 - does not conform No range error on a.push(1) returns 0, creates a non-array index property named "4294967295" and sets length to 0 Safari 3.1.2 - does not conform No range error on a.push(1) returns 0, creates a non-array index property named "4294967295" and sets length to 0
IE8 - does not conform No range error on a.push(1) returns 0, creates a non-array index property named "-1" and sets length to 0
It's possible that developmental builds of the above produce different results. As there is significant variance I don't see a strong reason to change the spec. to reflect the FF behavior.
It might be arguably better if pop threw the range error before creating any new properties. This would be easy to specify (and detect in implementations) for pop but for consistency that approach should probably also be applied to all the Array.prototype functions and it might be considerably harder to specify/implement such pre-flight checking for some of the more complex algorithms particularly in the presences of accessor properties with side-effects.
In an earlier draft I tried to say that final state of the array was unspecified if any exception was thrown but there was considerable negative reaction to that proposal.
Obviously I meant "push" rather than "pop" in the second to last paragraph
On Wed, May 13, 2009 at 10:19 AM, Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com> wrote:
Firefox 3.0.8 - does not conform No range error on a.push(1) returns 0, creates a non-array index property named "4294967295" and sets length to 0
It's possible that developmental builds of the above produce different results. [...]
In dev builds Firefox now conforms with ES3 on this point.
It isn't worth changing this. The general mess can't be cleaned up, and this particular case seems unlikely to hurt anyone in practice.
On May 13, 2009, at 8:33 AM, Jason Orendorff wrote:
On Wed, May 13, 2009 at 10:19 AM, Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com> wrote:
Firefox 3.0.8 - does not conform No range error on a.push(1) returns 0, creates a non-array index
property named "4294967295" and sets length to 0It's possible that developmental builds of the above produce
different results. [...]In dev builds Firefox now conforms with ES3 on this point.
And in Firefox 3.5 betas -- I wanted to clarify that "dev builds" does
not mean only the release after 3.5.
It isn't worth changing this. The general mess can't be cleaned up, and this particular case seems unlikely to hurt anyone in practice.
It's totally an edge case, but if everyone agrees, it will probably
get spec'ed at some point. For ES5, probably not -- up to Allen at
this point.
From: Brendan Eich
It's totally an edge case, but if everyone agrees, it will probably get spec'ed at some point. For ES5, probably not -- up to Allen at this point.
It's already spec'ed to throw in both ES3 and ES5. It's in Array instance's [[DefineOwnProperty]] in ES5 and [[Put]] for ES3.
On May 13, 2009, at 11:44 AM, Allen Wirfs-Brock wrote:
From: Brendan Eich
It's totally an edge case, but if everyone agrees, it will probably get spec'ed at some point. For ES5, probably not -- up to Allen at this point.
It's already spec'ed to throw in both ES3 and ES5. It's in Array
instance's [[DefineOwnProperty]] in ES5 and [[Put]] for ES3.
Sorry, I meant the issue James raised: the property is bound and then
RangeError is thrown. Seems like error-checking should happen before
any effects are committed.
-----Original Message----- From: Brendan Eich [mailto:brendan at mozilla.com]
Sorry, I meant the issue James raised: the property is bound and then RangeError is thrown. Seems like error-checking should happen before any effects are committed.
In general, it's probably not possible to pre-check all possible errors when you consider all the array functions, some of which are fairly complex and all the possible exceptions arising from running properties with strange attribute settings and/or getter/setters properties.
I wanted to say that the state of the array is unspecified if any exception is thrown by these functions but the security lobby objected so the spec. still implicitly requires that stores and exceptions occur in the specified algorithmic order. Of course, I don't really expect implementers to pay any more attention to that requirement then they have in the past, particularly if it gets in the way of seriously optimization opportunities.
Allen Wirfs-Brock wrote:
-----Original Message----- From: Brendan Eich [mailto:brendan at mozilla.com]
Sorry, I meant the issue James raised: the property is bound and then RangeError is thrown. Seems like error-checking should happen before any effects are committed.
In general, it's probably not possible to pre-check all possible errors when you consider all the array functions, some of which are fairly complex and all the possible exceptions arising from running properties with strange attribute settings and/or getter/setters properties.
I wanted to say that the state of the array is unspecified if any exception is thrown by these functions but the security lobby objected so the spec. still implicitly requires that stores and exceptions occur in the specified algorithmic order. Of course, I don't really expect implementers to pay any more attention to that requirement then they have in the past, particularly if it gets in the way of seriously optimization opportunities.
I agree with Allen here. The presence of side effects to the array should be unspecified if such an exception is thrown. This is what seems to happen in practice, whether we like it or not.
Waldemar
As far as I can tell, the ES5-specified behavior of
a = new Array() a.length = Math.pow(2,32)-1 a.push(1)
is to create a non-array-index property of the array with name 4294967296 (i.e. 2^32) and value 1 before throwing a RangeError hen trying to update the length. However this property isn't created in the majority of implementations (at least it doesn't happen in my builds of Spidermonkey, V8 and Squirrelfish) and since it is rather surprising that the operation would, in some sense, succeed before throwing an error, it seems like it might be nice to change this part of the spec to reflect the implementations.