mirror of https://github.com/svaarala/duktape.git
Sami Vaarala
9 years ago
2 changed files with 100 additions and 0 deletions
@ -0,0 +1,52 @@ |
|||
/*
|
|||
* Test 'this' binding for eval code: https://github.com/svaarala/duktape/issues/164
|
|||
*/ |
|||
|
|||
/*===
|
|||
*** test_1 (duk_safe_call) |
|||
non-strict eval from C |
|||
not an error in non-strict mode |
|||
object |
|||
object |
|||
strict eval from C |
|||
ReferenceError |
|||
object |
|||
object |
|||
final top: 0 |
|||
==> rc=0, result='undefined' |
|||
===*/ |
|||
|
|||
static duk_ret_t test_1(duk_context *ctx) { |
|||
/* For non-strict eval code the 'this' binding was effectively
|
|||
* the global object even before fixing GH-164: an undefined |
|||
* 'this' binding gets promoted to the global object by the |
|||
* usual Ecmascript call handling semantics. |
|||
*/ |
|||
duk_eval_string(ctx, |
|||
"print('non-strict eval from C');\n" |
|||
"try { dummy1 = 1; print('not an error in non-strict mode'); } catch (e) { print(e.name); }\n" |
|||
"print(typeof this);\n" |
|||
"print(typeof (this || {}).Math);\n" |
|||
); |
|||
duk_pop(ctx); |
|||
|
|||
/* For strict eval code the 'this' binding was undefined when
|
|||
* eval was being done from C code (but was the global object |
|||
* when done from Ecmascript code). With GH-164 fixed the |
|||
* 'this' binding is global object for strict eval code too. |
|||
*/ |
|||
|
|||
duk_eval_string_noresult(ctx, |
|||
"'use strict'\n" |
|||
"print('strict eval from C');\n" |
|||
"try { dummy2 = 1; print('error in strict mode'); } catch (e) { print(e.name); }\n" |
|||
"print(typeof this);\n" |
|||
"print(typeof (this || {}).Math);\n" |
|||
); |
|||
printf("final top: %ld\n", (long) duk_get_top(ctx)); |
|||
return 0; |
|||
} |
|||
|
|||
void test(duk_context *ctx) { |
|||
TEST_SAFE_CALL(test_1); |
|||
} |
@ -0,0 +1,48 @@ |
|||
/* |
|||
* Demonstrate 'this' binding behavior for "direct calls to eval" made |
|||
* from Ecmascript code. The behavior for both strict and non-strict is |
|||
* the same: the 'this' binding is inherited from the calling context, |
|||
* see E5.1 Section 10.4.2: |
|||
* |
|||
* - Step 2 will match (direct call) and establish a 'this' binding |
|||
* in step 2.a, independent of target code strictness. |
|||
* |
|||
* - Step 3 will match for strict code only and will update the lexical |
|||
* environment, but the 'this' binding is not affected. |
|||
* |
|||
* The C API eval behavior (duk_(p)eval_*) was different prior to Duktape 1.3: |
|||
* eval code 'this' binding was the global object for non-strict eval code, |
|||
* but undefined for strict eval code. This was fixed as part of GH-164: |
|||
* |
|||
* https://github.com/svaarala/duktape/issues/164
|
|||
*/ |
|||
|
|||
/*=== |
|||
non-strict eval code |
|||
not an error in non-strict code |
|||
object |
|||
object |
|||
strict eval code |
|||
ReferenceError |
|||
object |
|||
object |
|||
===*/ |
|||
|
|||
function test() { |
|||
eval("print('non-strict eval code');\n" + |
|||
"try { dummy1 = 1; print('not an error in non-strict code'); } catch (e) { print(e.name); }\n" + |
|||
"print(typeof this);\n" + |
|||
"print(typeof (this || {}).Math);\n"); |
|||
|
|||
eval("'use strict';\n" + |
|||
"print('strict eval code');\n" + |
|||
"try { dummy2 = 1; print('error in non-strict code'); } catch (e) { print(e.name); }\n" + |
|||
"print(typeof this);\n" + |
|||
"print(typeof (this || {}).Math);\n"); |
|||
} |
|||
|
|||
try { |
|||
test(); |
|||
} catch (e) { |
|||
print(e.stack || e); |
|||
} |
Loading…
Reference in new issue