The MDN documentation of strict mode covers approximately the same scope as this article, and quite a bit more, in a way that I find much easier to follow (it’s reference, whereas this article is narrative):
> The "use strict" directive can only be applied to the body of functions with simple parameters. Using "use strict" in functions with rest, default, or destructured parameters is a syntax error.
function sum(a = 1, b = 2) {
// SyntaxError: "use strict" not allowed in function with default parameter
"use strict";
return a + b;
}
Not that I would see myself doing this, I would put strict mode in a function containing all the code of the file that does not take any argument (or maybe dependencies), but why would "use strict"; be forbidden here?
Actually, yes. default parameter values could contain things that are allowed in sloppy mode and are syntax errors in strict mode. For instance, a leading zero in numbers without explicitly specifying the base, duplicate property names, the with statement, new reserved words and using delete on a variable name.
You need to disallow those in the parameter values in strict mode, but you only know this after encountering the "use strict" marking in the function body if you were not already in strict mode. You can make a parser able to do this, but it is more complex. I guess they decided that this complexity is not worth it.
A bit hard to understand this transcript without context but it really reads like SpiderMonkey and Chakra were actually able to parse this. V8 people didn't like it, the others were like "ok, whatever" and they ended up disallowing it in the spec.
I guess it allows simplifications in the parsers by not having a "strict or sloppy, don't know" mode for default parameter values, while not blocking actual use cases.
> In strict mode it's no longer possible to "walk" the JavaScript stack. Many implementations used to implement some extension features that make it possible to detect the upstream caller of a function. When a function fun is in the middle of being called, fun.caller is the function that most recently called fun, and fun.arguments is the arguments for that invocation of fun. Both extensions are problematic for "secure" JavaScript because they allow "secured" code to access "privileged" functions and their (potentially unsecured) arguments.
This affects V8's stack frames as well [1]. Is this related to the principle of least privilege? Can someone explain what specific vulnerability could result from allowing "secured code to access privileged functions and their (potentially unsecured) arguments" in Javascript?
your login function receives a username and a password from the form, checks them with a network call, and then sends an "user logged" event by calling a function of a third party library like Google Analytics or Sentry. Now it would be quite dangerous if the code in that function could access the parameters of the original caller which include sensitive data. This gets worse as you consider the entire supply chain of dependencies.
Does this really make a practical difference? In your example malicious dependency code could just add a keydown listener on the document to lift a password.
The first time, it gave jQuery, which notably inherited the $ and the terser syntax from perl. The second time, indeed, JS found Perl's "use strict" quite cute.
It was originally `use strict` without any quotes, along with other possible `use ...` statements in the scrapped ES4 working draft. It seems that the exact person suggested this particular syntax was David-Sarah Hopwood [1], which suggestion was quickly adopted to the next draft of what eventually became ES5.
It was good that it's a string literal, so it did not make the file incompatible with parsers that didn't support strict mode. You'd have to make sure your code behaved correctly both in sloppy mode and in strict mode.
That indeed was a big concern, and the initial proposal assumed that it at least has to survive the lexical analysis. At some point there were two syntaxes, `use strict` (optionally followed by a comma and other tokens) or `if (false) use(strict)` at one's choice. In comparison Hopwood's proposal was not even an actual proposal but quickly adopted due to its simplicity and robustness. The only complaint was a space in the literal.
At least Perl "uses" `use` for more things than just strict mode.
As a beginner, I remember finding this magical literal that (might) alter JS behavior pretty strange, especially since there were no other `use` directives.
I really like Perl's `use diagnostics` directive, which provides more verbose error messages, and am frankly surprised a far more popular language that is supposed to be beginner-friendly does not have something similar.
16 comments
[ 3.2 ms ] story [ 53.9 ms ] threadhttps://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
> The "use strict" directive can only be applied to the body of functions with simple parameters. Using "use strict" in functions with rest, default, or destructured parameters is a syntax error.
Not that I would see myself doing this, I would put strict mode in a function containing all the code of the file that does not take any argument (or maybe dependencies), but why would "use strict"; be forbidden here?I thought that parsing completed before execution, so why couldn’t the parser generate the same AST for these two functions?
(a) => a === undefined ? 1 : a
(a = 1) => a
Actually, yes. default parameter values could contain things that are allowed in sloppy mode and are syntax errors in strict mode. For instance, a leading zero in numbers without explicitly specifying the base, duplicate property names, the with statement, new reserved words and using delete on a variable name.
You need to disallow those in the parameter values in strict mode, but you only know this after encountering the "use strict" marking in the function body if you were not already in strict mode. You can make a parser able to do this, but it is more complex. I guess they decided that this complexity is not worth it.
A bit hard to understand this transcript without context but it really reads like SpiderMonkey and Chakra were actually able to parse this. V8 people didn't like it, the others were like "ok, whatever" and they ended up disallowing it in the spec.
I guess it allows simplifications in the parsers by not having a "strict or sloppy, don't know" mode for default parameter values, while not blocking actual use cases.
This affects V8's stack frames as well [1]. Is this related to the principle of least privilege? Can someone explain what specific vulnerability could result from allowing "secured code to access privileged functions and their (potentially unsecured) arguments" in Javascript?
https://v8.dev/docs/stack-trace-api#:~:text=strict%20mode
The first time, it gave jQuery, which notably inherited the $ and the terser syntax from perl. The second time, indeed, JS found Perl's "use strict" quite cute.
[1] https://web.archive.org/web/20150525070848/https://mail.mozi...
Probably irrelevant today.
As a beginner, I remember finding this magical literal that (might) alter JS behavior pretty strange, especially since there were no other `use` directives.
I really like Perl's `use diagnostics` directive, which provides more verbose error messages, and am frankly surprised a far more popular language that is supposed to be beginner-friendly does not have something similar.