eval operator with != 1 arguments

Mike Samuel mikesamuel at gmail.com
Thu Jan 14 18:27:43 PST 2010


Any thoughts on whether (eval(a, b)) should be an invocation of the
eval operator?

2010/1/8 Mike Samuel <mikesamuel at gmail.com>:
> Should it be the case that invoking unoverridden eval with 0 or 2 or
> more arguments is an EvalError, regardless of whether the call is
> direct or not?
>
> What is the behavior of
>  eval()
> and
>  eval("alert('Hello, World!')", void 0)
> ?
>
> Section 15.1.2.1 eval (x) specifies the behavior of the eval function
>    "When the eval function is called with one argument x, the
> following steps are taken:"
> but section 15.1.2.1.1 specifies the behavior of the eval operator
> without mention to # of arguments
>
>    "A direct call to the eval function is one that is expressed as a
> CallExpression
>    that meets the following two conditions:
>    1. The Reference that is the result of evaluating the
> MemberExpression in the
>    CallExpression has an environment record as its base value and its reference
>    name is "eval".
>    2. The result of calling the abstract operation GetValue with that Reference
>    as the argument is the standard built-in function defined in 15.1.2.1."
>
> Sections 10.4.2 Entering eval code, and later the addenda both switch
> on the use of direct call but without any extra language about extra
> parameters.
>    "15.1.2.1. Implementations are no longer permitted to restrict the
> use of eval in
>    ways that are not a direct call.  In addition, any invocation of
> eval that is not a
>    direct call uses the global environment as its variable
> environment rather than
>    the caller’s variable environment."
>
>
> Since the direct call to eval distinction does not depend on the
> number of arguments, it seems that
>  eval("alert('Hello, World!')", void 0)
> should resolve alert in the local environment and ignore the second
> and subsequent parameters.
> And that the behavior of
>  (0, eval)("alert('Hello, World!')", void 0)
> is undefined because there is no else clause in section 15.1.2.1.
>


More information about the es-discuss mailing list