php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #79175 Different results between 7.3 and 7.4 when using \p{N} character property
Submitted: 2020-01-27 15:20 UTC Modified: 2020-04-06 12:46 UTC
Votes:14
Avg. Score:4.9 ± 0.5
Reproduced:14 of 14 (100.0%)
Same Version:13 (92.9%)
Same OS:13 (92.9%)
From: php at spamscan dot biz Assigned:
Status: Suspended Package: PCRE related
PHP Version: 7.4.2 OS: Debian Linux
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2020-01-27 15:20 UTC] 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
)


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2020-01-27 16:08 UTC] nikic@php.net
Works with pcre.jit=0, so I'd expect this to be a PCRE JIT bug.
 [2020-01-27 16:48 UTC] 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 17:01 UTC] 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 18:49 UTC] requinix@php.net
-Status: Open +Status: Not a bug
 [2020-01-27 18:49 UTC] 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 19:12 UTC] php at spamscan dot biz
$> ./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
 [2020-01-27 19:25 UTC] nikic@php.net
-Status: Not a bug +Status: Re-Opened
 [2020-01-27 19:25 UTC] nikic@php.net
Also still fails on master, which was recently upgraded to 10.34.
 [2020-01-27 20:51 UTC] requinix@php.net
But this is still an upstream bug, right?
 [2020-04-06 12:46 UTC] cmb@php.net
-Status: Re-Opened +Status: Suspended
 [2020-04-06 12:46 UTC] cmb@php.net
Since this is obviously an upstream bug, which is supposed to be
fixed in PCRE2 10.35, I'm suspending this ticket.
 [2020-05-14 12:47 UTC] bugreports at gmail dot com
> Since this is obviously an upstream bug, which is supposed to be
> fixed in PCRE2 10.35, I'm suspending this ticket

well, Fedora starts to ship 10.35, time to cope

* Mo Mai 11 2020 Petr Pisar <ppisar@redhat.com> - 10.35-1
- 10.35 bump
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 19 05:01:29 2024 UTC