ES1-3 eval-created function bindings can be used to destroy caller bindings

Allen Wirfs-Brock Allen.Wirfs-Brock at microsoft.com
Fri Feb 13 09:44:57 PST 2009


>ES3.1 changes the rules to use CreateMutableBinding when entering the
>eval execution context only if x is not already bound, and in any case
>then to call SetMutableBinding (10.2.1.2.3 in the feb09 draft).
>SetMutableBinding calls [[ThrowingPut]]. Strict mode adds value in its
>own way but let's assume it's not used in the following.

[[ThrowingPut]] would not be called in the example given.  x has a mutable binding in a Declarative Environment Record so SetMutableBinding simply records the value without involving [[ThrowingPut]].  However, the issue Brendan raises would occur in scenarios where x resolved to a binding in an Object Environment Record (ie, the global environment or a property of a with bound object).  The same outcome would occur if this global code was executed:
   var x = a * a;
   eval("function x() { return 'ha ha!'; }");
   alert(x);

Brendan actually gets around to saying this but I found it a bit buried in the message so I wanted to re-emphasize the point that this issue applied only to globals and with bound names.

I'm not yet convinced that this really is a significant ES3 to ES3.1 compatibility issues. The potential incompatibilities all seem to involve either side effects of getter/setter properties or explicit attribute manipulation.  Since neither of these are a part of ES3 it would have to  be occurring in existing code using implementation depended means (language extensions or implementation magic). Code that depended upon such implementation characteristics would not be portable among ES3 implementations and hence I don't think there should be expectations that it would be portable to an conforming ES 3.1 implementation. That said, I do think we want to be respectful of the existing implementations and not unnecessarily break code that depends non-standard features in existing ES3 implementations.

I don't see that the specified behavior would be a problem for new code, written specifically to use ES 3.1 features including accessor properties and attribute manipulation. I believe that the current ES3.1 draft is complete and consistent in what will happen when those features are used in conjunction binding instantiation in Object Environment Records.  New code that uses 3.1 features should expect to get 3.1 semantics.

I do think that I could probably fix the concern with some rewriting of 10.6 (Binding Instantiation) and the Environment Record interface/implementation to ensure that functions get a "fresh" property in the binding objects.  However, I'm reluctant to mess with already "debugged code", ie the specification, at this point unless this is more than a hypothetical problem.

Can anybody identify any real scenarios based upon existing implementations and existing code where this change in semantics is actually going to cause a forward compatibility problem?

Allen 



More information about the Es-discuss mailing list