514559 - ES5 strict mode: octal integer literals and octal escape sequences are not allowed

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Jim Blandy :jimb]

In ES5 strict mode, octal integer literals (010 == 8) are not permitted, nor are octal escape sequences ("\040" == " ").

Comment 1

[Jim Blandy :jimb]

An entertaining test case.  The following is required to raise a SyntaxError:

function foo() {
   "asterisk: \052" // octal escape sequences forbidden in strict mode
   "use strict"
}

Comment 2

[Jim Blandy :jimb]

Attachment: Forbid octal literals or escape sequences in strict mode.

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 404909 [details] [diff] [review]
Forbid octal literals or escape sequences in strict mode.

>diff --git a/js/src/jsscan.cpp b/js/src/jsscan.cpp
>+                    if (!js_ReportES5StrictError(cx, ts, NULL, NULL,
>+                                                 JSMSG_STRICT_OCTAL))
>                         goto error;

Nit: braces around the consequent if the condition is multiline.

>+                        // ES5 strict mode allows only \0, then a non-digit.
>+                        if (val != 0 || JS7_ISDEC(c)) {
>+                            if (!js_ReportES5StrictError(cx, ts, NULL, NULL,
>+                                                         JSMSG_STRICT_OCTAL))
>+                                goto error;

Nit: Ditto here.

Comment 4

[Jim Blandy :jimb]

(In reply to comment #3)
> (From update of attachment 404909 [details] [diff] [review])
> >diff --git a/js/src/jsscan.cpp b/js/src/jsscan.cpp
> >+                    if (!js_ReportES5StrictError(cx, ts, NULL, NULL,
> >+                                                 JSMSG_STRICT_OCTAL))
> >                         goto error;
> 
> Nit: braces around the consequent if the condition is multiline.

Thanks --- fixed both cases.  I'll look through the other patches to see if I've missed any.

Comment 5

[Brendan Eich [:brendan]]

Again rather than ES5, which will age badly (although it commemorates de-jure strict mode's introduction), how about just js_ReportStrictModeError, to keep the strict mode vs. option distinction boiling, or simmering?

/be

Comment 6

[Jim Blandy :jimb]

(In reply to comment #5)
> Again rather than ES5, which will age badly (although it commemorates de-jure
> strict mode's introduction), how about just js_ReportStrictModeError, to keep
> the strict mode vs. option distinction boiling, or simmering?

Sure.

Comment 7

[Jim Blandy :jimb]

Attachment: Forbid octal literals or escape sequences in strict mode.

Now, with tests!

Comment 8

[Jim Blandy :jimb]

Comment on attachment 406571 [details] [diff] [review]
Forbid octal literals or escape sequences in strict mode.

Code changes are the same; added tests.

Comment 9

[Jim Blandy :jimb]

Attachment: Forbid octal literals or escape sequences in strict mode.

Tests revised per jorendorff's and waldo's comments.

Comment 10

[Jim Blandy :jimb]

http://hg.mozilla.org/tracemonkey/rev/43f456d9b632

Comment 11

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/43f456d9b632

Comment 12

[Eli Grey (:sephr)]

How exactly is this good? It forces JavaScript libraries that want to use strict mode for extra speed that deal with binary strings to be much more verbose (\x00\x01\x02\x03 vs \0\1\2\3) and to use the decimal base in bitwise operations whereas octal might be preferred (0100 vs 64).

Implementing this part of ECMAScript 5 has broken one of my libraries that handles binary formats as I assumed somebody sane would remove forbidding octals from ECMAScript 5 before anyone implemented it. I have since fixed my library but I'm assuming that other libraries may be affected too.

Comment 13

[Eli Grey (:sephr)]

Also, octal escape sequences are still allowed in regular expressions with the current implementation.

Comment 14

[Eli Grey (:sephr)]

Another bug I found: uneval("\x00") === "\\0", which is invalid for strict mode.

Comment 15

[Brendan Eich [:brendan]]

Elijah, thanks for filing. I've raised the issue and the direction among people such as Allen Wirfs-Brock, ES5 Editor, seems good:

https://mail.mozilla.org/pipermail/es5-discuss/2010-February/003507.html

As Allen says, we on Ecma TC39 should come up with a blessed list of extensions that address problems such as this one, and get them implemented. Glad to see Jim taking this bug.

/be