Closed carenas closed 1 year ago
Hmm. Yes, this is a moot point. I was making PCRE2 consistent in always allowing spaces for data in braces (like Perl) but since this is not a Perl-compatible feature, I guess we should go along with Javascript.
Oh dear. We now have another issue. The sequence \u{ 12} (when in BSUX mode) should be treated as a literal, and indeed it is in 10.42. But now, because spaces are allowed in quantifiers, it is treated as u{12}, because the \u is treated as a literal "u". This is going to be tedious to fix, but I guess I'll have to do it. The law of unintended consequences strikes again.
Since in BSUX mode any \x
character represents itself then the effect is indeed wider and so it might be worth disabling the space cleaning even for the quantifier to solve it, at least when in BSUX mode.
Note that Javascript (as well as POSIX) does not recognize x{,m}
as valid either.
I have fixed the \u{ 12} case so it is now compatible. The fix is in HEAD. I added a note about {,m} to the docs; there will always be differences between engines, but I think Perl compatibility has to come first. BSUX mode is documented to affect only some very specific things.
On Sat, 30 Sept 2023, 18:08 Carlo Marcelo Arenas Belón, < @.***> wrote:
Since in BSUX mode any \x character represents itself then the effect is indeed wider and so it might be worth disabling the space cleaning even for the quantifier to solve it, at least when in BSUX mode.
Note that Javascript (as well as POSIX) does not recognize x{,m} as valid either.
— Reply to this email directly, view it on GitHub https://github.com/PCRE2Project/pcre2/pull/297#issuecomment-1741815877, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG4QUABAYJS4DGRGXMU2ZBDX5BG2HANCNFSM6AAAAAA5LVKYFM . You are receiving this because you modified the open/close state.Message ID: @.***>
Avoid regressions by matching the observed behaviour of Javascript when the PCRE2_EXTENDED_ALT_BSUX option is in effect, and make sure to document the exception.