Assigning to globals in strict mode

Allen Wirfs-Brock Allen.Wirfs-Brock at microsoft.com
Wed Oct 20 08:28:01 PDT 2010


> 
> The RHS  (rref) is evaluated before PutValue has a crack at throwing the error,
> which seems to be the exact order-of-evaluation issue.
>

I agree.  The error is inevitable after competing step 1, so it shouldn't be waiting for the PutValue in step5  to actually throw the error.  If we want to consider this a bug, the fix would be to insert a new step after step 1 that says:

If IsStrictReference(lref) and isUnresolvableReference(lref) then throw ReferenceError exception

> 
> Since Oliver raised it, we could try to fix it in current implementations if we had
> an erratum with an extra step as a fix. But we'd have to develop the fix -- I'm not
> sure it is worth it right now.
>

The above seems like a reasonable fix that I can put into the errata if we have general agreement.  I probably also need to do a quick check to see if there are any other situations like this.  I'm less inclined to do something about the opposite situation that the delete chase exposes.

Allen

> -----Original Message-----
> From: Brendan Eich [mailto:brendan at mozilla.org]
> Sent: Tuesday, October 19, 2010 11:33 PM
> To: Allen Wirfs-Brock
> Cc: Maciej Stachowiak; Mark S. Miller; es5-discuss es5-discuss at mozilla.org
> Subject: Re: Assigning to globals in strict mode
> 
> On Oct 19, 2010, at 10:13 PM, Allen Wirfs-Brock wrote:
> 
> >> "use strict"; undeclared = global.undeclared = 5; This is allowed by
> >> ES5 strict.
> >
> > I don't think so:
> 
> You're right, so Firefox does have a bug here.
> 
> 
> > 11.13.1
> > step 1 creates lref as a reference to 'undeclared'. It is a unresolved reference.
> Its base value is undefined.
> > step 2 creates rref by evaluating the AssignmentExpresion.  It will be the value
> 5.
> > Step 3 assigns the value of GetValue(5) to rval.  It is still the value 5.
> > Step 4 does nothing because the name of lref is neither "eval" or "arguments"
> > Step 5 calls PutValue(lref,5)
> > 8.7.2 PutValue
> > Step 3  V (the value of lref) is found to be an UnresolvedReference because its
> vase value is undefined.
> > Step 3.a.i throws a ReferenceError because V is a strict mode Reference.
> 
> The RHS  (rref) is evaluated before PutValue has a crack at throwing the error,
> which seems to be the exact order-of-evaluation issue.
> 
> 
> > However this also means that: "use strict";  this.x = 1;  x = delete
> > this.x; recreates the global property x after first deleting it. ...
> > The delete behavior really seems unfortunate for strict mode but it
> > isn't clear that it is easy to correct if that is desired.  It would
> > probably require an extra step in 10.2.1.1.3
> 
> Since Oliver raised it, we could try to fix it in current implementations if we had
> an erratum with an extra step as a fix. But we'd have to develop the fix -- I'm not
> sure it is worth it right now.
> 
> Even with an erratum, would all the current browsers have time to implement
> the fix? It's an edge case, but conformance testing and our desire to
> interoperate would push us to match one another, if schedules and code freezes
> allow.
> 
> /be
> 



More information about the es5-discuss mailing list