Bug #79175 [Com]: Different results between 7.3 and 7.4 when using \p{N} character property

Edit report at https://bugs.php.net/bug.php?id=79175&edit=1 ID: 79175 Comment by: php at spamscan dot biz Reported by: php at spamscan dot biz Summary: Different results between 7.3 and 7.4 when using \p{N} character property Status: Not a bug Type: Bug Package: PCRE related Operating System: Debian Linux PHP Version: 7.4.2 Block user comment: N Private report: N New Comment: $> ./pcre2test -jit PCRE2 version 10.34 2019-11-21 re> /[\p{Latin}\p{N}]+/ data> Text1234567890Text 0: Text $> ./pcre2test PCRE2 version 10.34 2019-11-21 re> /[\p{Latin}\p{N}]+/ data> Text1234567890Text 0: Text1234567890Text still not working in v.10.43 Previous Comments: ------------------------------------------------------------------------ [2020-01-27 18:49:37] requinix@php.net Looks like https://bugs.exim.org/show_bug.cgi?id=2432. Can someone try building and testing with PCRE 10.34? ------------------------------------------------------------------------ [2020-01-27 17:01:11] bugreports at gmail dot com and that's why the buldeled pcre libraries should really get updated not only within major releases, there is an endless amount of fixed bugs upstream not talking about distribution specifix fixes all the time if you just look at the pcre/cpre2 changelog of Fedora you start to puke thinking that notihing or only a minority of that stuff is fixed within PHP ------------------------------------------------------------------------ [2020-01-27 16:48:53] php at spamscan dot biz yes, thats seems to be the problem: $> ./pcre2test -jit PCRE2 version 10.33 2019-04-16 re> /[\p{Latin}\p{N}]+/ data> Text1234567890Text 0: Text $> ./pcre2test PCRE2 version 10.33 2019-04-16 re> /[\p{Latin}\p{N}]+/ data> Text1234567890Text 0: Text1234567890Text data> ------------------------------------------------------------------------ [2020-01-27 16:08:47] nikic@php.net Works with pcre.jit=0, so I'd expect this to be a PCRE JIT bug. ------------------------------------------------------------------------ [2020-01-27 15:20:38] php at spamscan dot biz Description: ------------ When using preg_match() to check against PCRE character properties, using different character properties, where one is \p{N}, the match fails. I've provided a short sample script with this bug report. A more thorough script that shows that the problem only occurs if \p{N} is combined with other character properties can be found here: https://3v4l.org/XFEue $> /opt/php/bin/php --info|grep configure Configure Command => './configure' '--prefix=/opt/php' '--exec-prefix=/opt/php' '--with-mysqli=mysqlnd' '--with-pear' '--enable-gd' '--with-freetype' '--with-zlib-dir=/usr/lib' '--with-config-file-path=/etc/' '--with-jpeg' '--with-openssl' '--with-curl' '--enable-mbstring' '--with-zip' '--enable-sockets' '--enable-phar' '--enable-pcntl' '--enable-intl' '--without-sqlite3' '--without-pdo-sqlite' It seems that this is not an PCRE problem. I've tested the regexp with PCRE2 v.10.33 (the one that comes bundled with php 7.4.2): $> ./pcre2test PCRE2 version 10.33 2019-04-16 re> /[\p{Latin}\p{N}]+/ data> Text1234567890Text 0: Text1234567890Text Test script: --------------- <?php $string = 'Text1234567890Text'; print_r(preg_match('/[\p{Latin}\p{N}]+/u', $string, $m)); echo "\n---\n"; print_r($m); Expected result: ---------------- excpected result (php version 7.3) $> php --version PHP 7.3.12 (cli) (built: Nov 28 2019 10:53:41) ( NTS ) test script output: 1 --- Array ( [0] => Text1234567890Text ) Actual result: -------------- actual result (php 7.4) $> php --version PHP 7.4.2 (cli) (built: Jan 27 2020 14:05:08) ( NTS ) test script output: 1 --- Array ( [0] => Text ) ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=79175&edit=1