indirect eval spec too severe?

David-Sarah Hopwood david.hopwood at industrial-designers.co.uk
Sat Jan 24 15:36:37 PST 2009


Mark S. Miller wrote:
> The Mountain View draft says:
> 
>> 15.1.2    Function Properties of the Global Object
>> 15.1.2.1    eval (x)
>> When the eval function is called with one argument x, the following steps
>> are taken:
>> [...]
>> If the value of the eval property is used in any way other than a direct
>> call (that is, other than by the explicit use of its name as an Identifier
>> which is the MemberExpression in a CallExpression), or if the eval property
>> is assigned to, an EvalError exception may be thrown.
>>
>> 15.1.2.1.1    Strict Mode Restrictions
>> If strict mode code uses the value of the eval property any way other than
>> as a direct call (that is, other than by the explicit use of its name as an
>> Identifier which is the MemberExpression in a CallExpression), or if the
>> eval property is assigned to, an EvalError exception is thrown.
> 
> I believe this spec is too severe, both for nonstrict and strict code. My
> sense of the committee consensus is that an indirect eval call should be
> unconditionally allowed, in which case the execution context should be the
> global execution context, as already adequately specified in 10.4.2. (In the
> committee's conversations, we've referred to the "direct calls" of the spec
> language as the "eval operator", and the spec's "indirect calls" as the
> "eval function". I'm happy with either terminology.)
>
> As for restrictions on assignment to "eval", so long as the global "eval"
> might be assigned by nonstrict code, it doesn't help much to prevent it's
> assignment by strict code. Rather, in a "frame" (global object context) in
> which we wish to prevent assignment of global "eval", one can
> Object.defineProperty(window,
> "eval", {writable: false, configurable: false}), preventing anyone from
> assigning it.

If the spec were changed to require that the global 'eval' property is
initially mutable, then that would imply that an implementation that
makes it initially immutable (using a setter that throws EvalError) would
not be conformant to ES3.1.

I see no reason why such an implementation should be considered
nonconformant. Do we really want any code to be mutating the global
'eval' property? Do we have any evidence that real-world code is doing
so? If not, then why change the spec to require it to work?

-- 
David-Sarah Hopwood ⚥



More information about the Es-discuss mailing list