On 2011/02/02 10:30:03, Mads Ager wrote:
What happens if you have an indirect call to eval from strict mode code.
Should
the eval compile in strict mode or not?
If it is direct call to eval, yes.
function f(this_could_be_eval, s) { this_could_be_eval(s); }
f(eval, "with (String.prototype) { ... }")
Should that throw an exception or not? This hits the builtin eval function
with
the global object as the scope currently. It does not go through the paths
that
you have modified. Is non-strict the right behavior for these global evals
through aliases?
This is correct. eval may not be aliased (otherwise it is not a direct call
to
eval and strict mode no longer passes through it, nor the current 'this'.
Instead, global object is provided as 'this')
http://codereview.chromium.org/6286043/diff/1/src/runtime.cc
File src/runtime.cc (right):
http://codereview.chromium.org/6286043/diff/1/src/runtime.cc#newcode7647
src/runtime.cc:7647: Handle<JSFunction>
caller(JSFunction::cast(frame->function()));
On 2011/02/02 05:07:26, Martin Maly wrote:
> Alternative to walking the stack frames is passing additional argument
(strict
> mode flag). This works well but am not sure whether it is the right way
to
do
> this. Open to suggestions.
When you are compiling the caller you know whether or not it is strict
mode so
I
would pass that in as an extra argument. Iterating stack frames is less
direct
and it is also not cheap.
http://codereview.chromium.org/6286043/diff/1/src/runtime.cc#newcode7671
src/runtime.cc:7671: JavaScriptFrame* frame =
locator.FindJavaScriptFrame(0);
On 2011/02/02 05:07:26, Martin Maly wrote:
> Alternative to walking the stack frames is passing additional argument
(strict
> mode flag). This works well but am not sure whether it is the right way
to
do
> this. Open to suggestions.
I would go for the additional argument here too.
http://codereview.chromium.org/6286043/
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
