Incorrect application of restriction on octal escape sequences

RESOLVED INVALID

Status

()

Core
JavaScript Engine
RESOLVED INVALID
3 years ago
3 years ago

People

(Reporter: jugglinmike, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
The character sequences '\08' and '\09' are evaluated correctly (as the null character followed by the '8' or '9' character, respectively), but restrictions relating to octal escape sequences are incorrectly applied. This is apparent both in string literals declared in strict-mode code and in template literals declared in any mode.

Correct evaluation:

    js> '\08'.replace(/\0/, 'null')
    "null8"
    js> '\09'.replace(/\0/, 'null') 
    "null9"

Erroneously-applied restriction:

    js> (function() { 'use strict'; '\08'; })
    typein:135:28 SyntaxError: octal literals and octal escape sequences are deprecated:
    typein:135:28 (function() { 'use strict'; '\08'; })
    typein:135:28 ............................^
    js> (function() { 'use strict'; '\09'; }) 
    typein:136:28 SyntaxError: octal literals and octal escape sequences are deprecated:
    typein:136:28 (function() { 'use strict'; '\09'; })
    typein:136:28 ............................^
    js> `\08`;
    typein:137:0 SyntaxError: octal literals and octal escape sequences are deprecated:
    typein:137:0 `\08`;
    typein:137:0 ^
    js> `\09`; 
    typein:138:0 SyntaxError: octal literals and octal escape sequences are deprecated:
    typein:138:0 `\09`;
    typein:138:0 ^
From the spec <http://people.mozilla.org/~jorendorff/es6-draft.html#sec-literals-string-literals>:

   A conforming implementation, when processing strict mode code (see 10.2.1), must not
   extend the syntax of EscapeSequence to include LegacyOctalEscapeSequence as described
   in B.1.2.

If you look at the EscapeSequence grammar in that section, it has:

   0 [lookahead ∉ DecimalDigit]

So \0 is allowed in a strict-mode literal only if not followed by a DecimalDigit.  8 is a DecimalDigit.

Similarly, http://people.mozilla.org/~jorendorff/es6-draft.html#sec-template-literal-lexical-components says:

  A conforming implementation must not use the extended definition of EscapeSequence
  described in B.1.2 when parsing a TemplateCharacter.

So as far as I can tell, we're doing exactly what the spec says to do.  Am I missing something?
Flags: needinfo?(mike)
But note also https://bugs.ecmascript.org/show_bug.cgi?id=3477 and https://bugs.ecmascript.org/show_bug.cgi?id=1553#c2
(Reporter)

Comment 3

3 years ago
It looks like I was mistaken--the runtime should generate an error because the `\` character is not followed by a valid Escape Sequence (as defined for strict mode code). Sorry for the confusion (and thanks for the link to the ECMAScript discussion--it's nice to know I'm not the only who has struggled with this!)

In light of that (and as a separate and even lower-priority issue), do you think the error message should be re-written? The engine is reporting that it recognizes and rejects an octal escape sequence, but neither '\08'  nor '\09' are octal escape sequences. The real problem is that `\08` is an invalid sequence.

Come to think of it, is there *any* definition of EscapeSequence (strict mode or not) that allows these forms?
Flags: needinfo?(mike)
(Reporter)

Comment 4

3 years ago
Actually, I can answer my own question this time. According to B.1.2

    LegacyOctalEscapeSequence ::
        OctalDigit [lookahead ∉ OctalDigit]
        ZeroToThree OctalDigit [lookahead ∉ OctalDigit]
        FourToSeven OctalDigit
        ZeroToThree OctalDigit OctalDigit

...this means that in all cases, '\08' evaluates to '\u0000\u0038' and '\09' evaluates to '\u0000\u00039'. The important detail that I've been missing is that this is true because of the definition of LegacyOctalEscapeSequence; the general EscapeSequence never comes into play in either strict mode *or* sloppy mode.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.