Argh, that's section 10.1.1, not 10.10.1, which specifies when eval code is
strict.
On Wed, Feb 2, 2011 at 13:37, Lasse R.H. Nielsen <l...@chromium.org> wrote:
> I just checked what Safari (or really: Webkit Nightly) does.
>
> 1. It doesn't follow the spec on whether an aliased call to eval is direct,
> if the aliasing variable is called "eval". I.e., our current behavior
> actually matches Safari/JSC, so that
> window.x = "global";alert(function(eval) { var x = "local"; return
> eval("x"); }(eval));
> alerts "global", not "local".
>
> So, for all my complaints about us not following the spec on eval, it's
> really irrelevant, since we match Safari.
> I'll close the bug until JSC changes, they probably will eventually (
> http://code.google.com/p/v8/issues/detail?id=994 ).
>
> 2. An indirect call to eval from a strict-mode context isn't itself treated
> as strict.
> I.e.
> (function(){"use strict"; var alias = eval; alias("var arguments"); })()
> doesn't throw a SyntaxError. That's spec compliant (section 10.10.1, second
> point).
>
> Cheers
> /L
>
> On Wed, Feb 2, 2011 at 11:30, <a...@chromium.org> wrote:
>
>> What happens if you have an indirect call to eval from strict mode code.
>> Should
>> the eval compile in strict mode or not?
>>
>> 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?
>>
>>
>>
>> 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/
>>
>
>
>
> --
> Lasse R.H. Nielsen
> l...@google.com
> 'Faith without judgement merely degrades the spirit divine'
> Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 København K -
> Denmark - CVR nr. 28 86 69 84
>
--
Lasse R.H. Nielsen
l...@google.com
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 København K -
Denmark - CVR nr. 28 86 69 84
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
