Closed Bug 514559 Opened 12 years ago Closed 12 years ago

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

Categories

(Core :: JavaScript Engine, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: jimb, Assigned: jimb)

References

(Blocks 1 open bug, )

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(1 file, 2 obsolete files)

In ES5 strict mode, octal integer literals (010 == 8) are not permitted, nor are octal escape sequences ("\040" == " ").
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"
}
Assignee: general → jim
Depends on: 514585
Attachment #404909 - Flags: review?(mrbkap)
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.
Attachment #404909 - Flags: review?(mrbkap) → review+
(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.
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
(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.
Now, with tests!
Attachment #404909 - Attachment is obsolete: true
Comment on attachment 406571 [details] [diff] [review]
Forbid octal literals or escape sequences in strict mode.

Code changes are the same; added tests.
Attachment #406571 - Flags: review?(mrbkap)
Attachment #406571 - Flags: review?(mrbkap) → review+
Tests revised per jorendorff's and waldo's comments.
Attachment #406571 - Attachment is obsolete: true
http://hg.mozilla.org/tracemonkey/rev/43f456d9b632
Status: NEW → ASSIGNED
Whiteboard: fixed-in-tracemonkey
Flags: in-testsuite+
http://hg.mozilla.org/mozilla-central/rev/43f456d9b632
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Depends on: 541455
No longer depends on: 541455
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.
Also, octal escape sequences are still allowed in regular expressions with the current implementation.
Another bug I found: uneval("\x00") === "\\0", which is invalid for strict mode.
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
You need to log in before you can comment on or make changes to this bug.