Inconsistent language regarding strict mode restrictions on eval

Dmitry A. Soshnikov dmitry.soshnikov at gmail.com
Tue Oct 12 01:27:20 PDT 2010


  On 12.10.2010 10:31, Jeff Walden wrote:
>> 10.4.2.1  Strict Mode Restrictions
>>
>> The eval code cannot instantiate variable or function bindings in the
>> variable environment of the calling context that invoked the eval if
>> either the code of the calling context or the eval code is strict code.
>> Instead such bindings are instantiated in a new VariableEnvironment
>> that is only accessible to the eval code.
>
> At risk of pedantry, this is not consistent with the remainder of ES5.
>
> First: the strictness of the calling context does not affect 
> calculation of eval code's variable environment if the call to eval 
> was indirect (10.4.2 step 3).  Second: for an indirect eval of 
> non-strict code, the variable environment used is the global environment.
>
> Therefore, if an indirect eval occurs at global level in strict code, 
> it *can* "instantiate variable or function bindings in the variable 
> environment of the calling context that invoked the eval" even though 
> "the code of the calling context...is strict code".  Further, "such 
> bindings are instantiated in a new VariableEnvironment" that is 
> accessible to other global code and to other Programs executed against 
> the global environment, and it is *not* "only accessible to the eval 
> code".
>

Hm, good catch. So, this all about that 10.4.2 exists on the step 1 
without mentioning about /strictVarEnv/ which appear only on step 3. 
However, it's just a (minor?) inconsistency of the 10.4.2 (step 1). 
Because after that 10.4.2.1 says what is eval strict variant (i.e. 
considering the strictness of the current calling context). Moreover, as 
I see in BESEN implementation now, such indirect eval's code is treated 
as strict though (that is, the implementation determines it based on 
10.4.2.1). So the erratum is to fix 10.4.2 step 1, as I understand you.

Dmitry.

> I suspect this paragraph was meant to be informative rather than 
> normative, and I assume most readers will treat it as such, referring 
> to the paragraph only for basic understanding, not exact detail.  Even 
> still, it shouldn't contradict the rest of the spec.
>
> Jeff
> _______________________________________________
> es5-discuss mailing list
> es5-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es5-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es5-discuss/attachments/20101012/d322f694/attachment.html>


More information about the es5-discuss mailing list