Bug #76909 [ReO]: preg_match difference between 7.3 and < 7.3

Edit report at https://bugs.php.net/bug.php?id=76909&edit=1 ID: 76909 Updated by: requinix@php.net Reported by: jay at diablomedia dot com Summary: preg_match difference between 7.3 and < 7.3 Status: Re-Opened Type: Bug Package: PCRE related Operating System: Linux PHP Version: 7.3.0RC1 Block user comment: N Private report: N New Comment: For the record, I can reproduce with pcre2test. (The backslash is required to escape the leading space.) re> /^[\x{0100}-\x{017f}]{1,63}$/i,utf,jit=0 data> \ domain.com No match data> re> /^[\x{0100}-\x{017f}]{1,63}$/i,utf,jit=1 data> \ domain.com 0: domain.com Previous Comments: ------------------------------------------------------------------------ [2018-09-21 06:21:21] nikic@php.net Reopening to track the update of the bundled libpcre2. ------------------------------------------------------------------------ [2018-09-20 23:29:06] requinix@php.net Marking NAB and I'll watch what happens with that report. ------------------------------------------------------------------------ [2018-09-20 21:53:29] jay at diablomedia dot com I filed a bug with PCRE: https://bugs.exim.org/show_bug.cgi?id=2321 I was able to confirm that disabling PCRE JIT does fix the issue. ------------------------------------------------------------------------ [2018-09-20 21:24:21] nikic@php.net This bug still reproduces on master, which uses PCRE 10.32, so it was not fixed as part of that release. ------------------------------------------------------------------------ [2018-09-20 21:08:28] requinix@php.net Looks like a PCRE bug because turning off JIT makes it work correctly again. So that's the workaround. ini_set("pcre.jit", 0); PHP 7.3 is currently bundling PCRE 10.31. Version 10.32-RC1 includes a fix for something that looks related. > 35. In a pattern such as /[^\x{100}-\x{ffff}]*[\x80-\xff]/ which has a repeated > negative class with no characters less than 0x100 followed by a positive class > with only characters less than 0x100, the first class was incorrectly being > auto-possessified, causing incorrect match failures. https://www.pcre.org/changelog.txt https://bugs.exim.org/show_bug.cgi?id=2300 While your example doesn't have the negated set, the fix for the bug was very simple so it could affect less complicated situations like yours as well. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=76909 -- Edit this bug report at https://bugs.php.net/bug.php?id=76909&edit=1