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