Problems with strict-mode caller poisoning

Jeff Walden jwalden+es at MIT.EDU
Fri Nov 16 13:19:20 PST 2012

On 11/16/2012 07:06 AM, Brendan Eich wrote:
>> d8>  function g() { Object.seal(g) }
>> d8>  function f() { "use strict"; g() }
>> d8>  f()
>> (d8):1: TypeError: Illegal access to a strict mode caller function.
>> (Interestingly, Firefox does not throw on that example, so I'm not
>> sure what semantics it actually implements.)
> It looks like SpiderMonkey's Object.{seal,freeze,isSealed,isFrozen} implementations do not call [[GetOwnProperty]] on each property. Cc'ing Jeff Walden.

They do, sort of, but .caller doesn't fit into the [[GetOwnProperty]] system well in SpiderMonkey because, on functions that are not themselves strict (or bound), it's neither a data property nor an accessor property.  That this happens to not complain vociferously is nearly happenstance at best.  (I suspect it did at one time, actually, and I bet I know the bug that changed it, but it doesn't really matter in the end.)

> So it seems to me premature to throw on [[GetOwnProperty]] of a strict function's 'caller'. It would be more precise, and avoid the problem you're hitting, to return a property descriptor with a censored .value, or a poisoned-pill throwing-accessor .value.

"premature to throw on [[GetOwnProperty]]("caller") on a function whose caller is strict", I assume you meant.  That seems right to me.  Since caller is a time-variant characteristic, it seems right for the property to be an accessor, probably existing solely on Function.prototype, and to defer all the strictness checks to when the function provided as |this| is actually invoked.

Such a property is no different from anything already in the language, so I can't see how it would at all interfere with Object.observe semantics or implementation.


More information about the es-discuss mailing list