Invalid decimal escape regex parse error about duktape HOT 6 CLOSED

The issue seems to be the \1 escape inside brackets: [^\\\1]. I'm not sure what the regexp is used for, but perhaps the \1 was escaped "just in case" and a literal 1 character was intended:

'pattern': /(\(|\s|\[|\=|:|\+|\.)(('|")([^\\1]|\\.)*?(\3))/gm

Looking at the standard's take on this, E5 only allows a '\0' DecimalEscape (U+0000) inside a character class. Other DecimalEscapes are treated as back references and rejected inside character classes. This happens in E5 Section 15.10.2.11 step 3, then E5 Section 15.10.2.19 step 2.

Unfortunately the major engines allow somewhat different regexp syntax than the standard. As a result there are naturally a lot of regexps in existing code bases which don't conform to E5. There's a work item to make regexp parsing more lenient to better support these. Some leniency has already been added, and adding support for this particular case would be quite straightforward too. Other known cases require backtracking which is a bit more work to implement.

from duktape.

Hmm. V8 doesn't seem to parse \1 inside a character class as a literal:

> p=/^[^\\\1]$/
> p.test('\\')
false
> p.test('1')
true

I'm not sure what it matches. It doesn't seem to match against a capture group either:

> p=/^(.)[^\1]$/
> p.test('xx')
true
> p.test('x1')
true

So... not sure what it matches without some further digging.

from duktape.

Thanks Sami, I disabled this pattern (it is part of a javascript parsing regex) and am still able to parse without issues so far, you might be right in the "escaped just in case". Regex is really hard to read/understand the moment you stop working on a specific one :)

What I meant by Chrome parsing it, is that it did't throw a syntax error and refuse to compile, which maybe it should.

from duktape.

Btw, I'm not saying that the specification behavior is necessarily "right" :) It's just something to implement against, and often real world behavior trumps a specification -- this is already the case with e.g. function statements and a few other minor things.

Adding "real world behavior" is more difficult because the requirements to implement against are more vague, so there's separate effort to figure out what the desired behavior is etc. Sometimes one "real world behavior" conflicts with another, and so on.

Anyway, let me know if you figure out the desired behavior of the pattern in this case :)

I'll keep this issue open for a short while at least, to ensure this gets into the list of regexp real world issues to write test cases against etc.

from duktape.

I haven't been able to discern that the pattern is even being used, feel free to close with extreme prejudice!

from duktape.

This is not yet fixed, but there's a (failing) testcase tracking it now.

from duktape.