Array lengthening methods applied to maximally long arrays

David-Sarah Hopwood david-sarah at jacaranda.org
Thu May 14 12:44:35 PDT 2009


Waldemar Horwat wrote:
> 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.

The security argument for following the specified algorithms precisely
is that it leads to more deterministic behaviour that is easier to test,
and easier for a secure subset designer to reason about.
Unfortunately, for security-oriented subsets of a language, apparently
trivial noncompliance to corner cases of the language spec can sometimes
lead to a complete break of the subset's security properties.

In this particular case, the consequence of some implementations
not following the spec precisely was that those implementations also
failed to maintain the array length invariant, which both programs and
secure subset runtimes are entitled to rely on. This is a demonstration
that following the specification precisely is important.

On the issue of optimization: there are many, many instances of
behaviour required by the ECMAScript spec that is far from ideal
with respect to optimisability. JavaScript is simply not an easily
optimisable language, because that wasn't a focus of its original
design -- and arguably, for the vast majority of web applications
that is not a significant problem. So the inability to optimize the
specified behaviour should never by itself be considered an excuse
for nonconformance.

As it happens, I don't think that there is any significant
optimisation precluded by strict adherence to the spec in this case.
I don't find the mere possibility that greater nondeterminism might
conceivably allow optimisations, in the absence of any concrete
suggestion of what those optimisations might be or evidence that
they would significantly affect the *overall* speed or memory usage
of realistic applications of JavaScript, to be a compelling argument.

-- 
David-Sarah Hopwood ⚥



More information about the es5-discuss mailing list