Bug 35856
| Summary: | '\d' passed to the RexExp::create as 'd' | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Balazs Kelemen <kbalazs> |
| Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | Normal | ||
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | PC | ||
| OS: | Linux | ||
Balazs Kelemen
'123xyz'.match(new RegExp('^\d+')) does not find a match.
When I set a breakpoint into RegExp::create I saw that it gets the pattern as '^d'.
This problem is hidden by the expected.html from the regtests.
I think this can be a parser (maybe lexer) bug or a bug of the bytecode generating.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Mark Rowe (bdash)
How is this not expected behavior? The JavaScript string literal ‘^\d+’ is treated same as ‘^d+’ since \d is not a recognized escape sequence. This happens long before regular expressions enter the picture. If you want the \d to be treated as the regular expression meta-character you need to to escape the backslash so that the string contains the characters \ and d in sequence, e.g, ‘^\\d+’.
Alexey Proskuryakov
For those curious about Firefox behavior, it's the same.
Balazs Kelemen
I had misinterpreted this regtest result:
'abc
123xyz'.match(new RegExp('^\d+')) = null FAILED! expected: 123
Sorry for my thoughtlessness.