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

From: Date: Mon, 27 Jan 2020 16:48:53 +0000
Subject: Bug #79175 [Com]: Different results between 7.3 and 7.4 when using \p{N} character property
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-225157@lists.php.net to get a copy of this message
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: Open Type: Bug Package: PCRE related Operating System: Debian Linux PHP Version: 7.4.2 Block user comment: N Private report: N New Comment: 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> Previous Comments: ------------------------------------------------------------------------ [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

« previous php.bugs (#225157) next »