indirect eval spec too severe?

Mark S. Miller erights at
Sun Jan 18 22:17:04 PST 2009

On Sun, Jan 18, 2009 at 8:47 PM, Brendan Eich <brendan at> wrote:

> On Jan 18, 2009, at 6:03 PM, Mark S. Miller wrote:
>  A related difficulty, not addressed by the above spec, is shadowing. Does
>> the following program contain a direct call to eval (i.e., a use of the
>> "eval operator")?
>>  function foo(eval, str) {
>>    return eval(str);
>>  }
> [...]  The standard approach is to check for a callee named 'eval' and emit
> a distinguished instruction which acts like the generic call instruction.
> [...] checking for a known identifer when parsing call expressions, [...] So
> the above eval call would be "apparently-direct", [...]
> Note that there's no way at runtime to change an apparently-direct eval
> into an indirect eval call. But an apparently-direct eval can turn into a
> plain old call.


 The eval variable being called here is not an alias for the "eval" property
>> of the global object, though it may or may not have the same value. If the
>> answer is that this is not a direct call,
> That's the wrong answer -- it should be direct purely because the callee
> name is 'eval'.

So the use of "property" in the spec:

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.

means the original *value* of the global eval property (in which case the
statement of the assignment constraint is wrong)? And "its name" above means
specifically "eval", whether referring to a property or a local variable?

 since the defining occurrence is local, then what about the second "eval"
> in the following code?
>  function foo(str1, str2) {
>    eval(str1);
>    eval(str2);
>  }

Same answer -- these are two "direct" eval calls by the compiler's lights.


>  Since foo may be called as foo('var eval = f', ..), the second eval may
>> refer to a local or to a global eval. These ambiguities defeat the goal of
>> distinguishing direct from indirect calls.
> Not in practical implementations that nevertheless do no expensive
> analyasis, as sketched above.

Given your other answers, I don't think we have a problem here.

>  Though the above specific problem cannot occur if foo is strict, I propose
>> that, for all code, one may not define a local variable named "eval".
> This is unnecessary, and I'm not sure it's sufficient given your
> assumptions.

I think I'm happy with your earlier assumptions above; in which case it
would be sufficient to prohibit defining local variables named "eval".

> But we shouldn't have to worry about any shadowing or rebinding issues if
> we can specify what popular implementations do.

What Firefox current does (3.0.5):

    function foo(a, b, c) { return a(b); }
    foo(eval, 'c', 42); // returns 42

More information about the Es-discuss mailing list