indirect eval spec too severe?

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


On Sun, Jan 18, 2009 at 8:47 PM, Brendan Eich <brendan at mozilla.com> 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.


Good.

 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.
>

Good.


>
>  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