Comment #5 on issue 981 by [email protected]: Primordial privilege escalation from bad this-coercion
http://code.google.com/p/v8/issues/detail?id=981

Built-in functions are not strict or non-strict, and entering them is not entering "function code" since they are not presumed to be written in JavaScript. Instead, each built-in function specifies its this-handling itself. For example, 15.4.4.10 Array.prototype.slice step 1 says:

1. Let O be the result of calling ToObject passing the this value as the argument.

This is the case for virtually all built-ins, and is new with ES5. We refactored it this way from ES3 so that strict only programs would still get the legacy wrapping behavior of the ES3 built-ins but not their global object leakage. A strict only program -- one without any non-strict (non-built-in) JavaScript code must be free of global object leakage. Otherwise much of the point of ES5 is lost.

The outlier from the above typical pattern is 15.2.4.2 Object.prototype.toString:

    1. If the this value is undefined, return "[object Undefined]".
    2. If the this value is null, return "[object Null]".
3. Let O be the result of calling ToObject passing the this value as the argument.

Were entry to this built-in treated according to 10.4.3 Entering Function Code, then steps 1 and 2 would be dead code -- clearly not the intent.

Of course, for bootstrapping an implementation may choose to write these built-ins in almost-JavaScript, i.e., JavaScript as modified to be able to refer to things like "the original Object" rather than the current binding of 'Object', as v8 has. Such bootstrapping can be handled by writing all such almost-self-hosted built-in functions as strict functions that explicit do something like

    function ArraySlice(start, end) {
      "use strict";
      var O = TO_OBJECT(this);
      ..
    }


--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev

Reply via email to