php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #80569 preg_match no empty (null or "") values in matches
Submitted: 2020-12-31 17:08 UTC Modified: 2021-01-01 14:29 UTC
Votes:1
Avg. Score:3.0 ± 0.0
Reproduced:0 of 1 (0.0%)
From: shardlow dot a at gmail dot com Assigned:
Status: Open Package: PCRE related
PHP Version: 7.4.13 OS: OSX Catalina
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: shardlow dot a at gmail dot com
New email:
PHP Version: OS:

 

 [2020-12-31 17:08 UTC] shardlow dot a at gmail dot com
Description:
------------
---
From manual page: https://php.net/function.preg-match
---



Test script:
---------------
       //print_r($_GET);
        //$value = '1:2.3';
        //$value = '1:2';
        $value = '2';
        $matches = '';
        preg_match('/^(\d{1,2}:)?(\d{1,2})(\.\d{1,2})?$/', $value, $matches);
        echo '<br>';
        echo '<br>';
        print_r($matches);
        echo '<br>';
        echo phpversion();

Expected result:
----------------
Array ( [0] => 2 [1] => [2] => 2 [3]=>)
7.3.11

Actual result:
--------------
Array ( [0] => 2 [1] => [2] => 2 )
7.3.11

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2020-12-31 20:18 UTC] requinix@php.net
-Status: Open +Status: Not a bug -Package: *Regular Expressions +Package: PCRE related
 [2020-12-31 20:18 UTC] requinix@php.net
Use PREG_UNMATCHED_AS_NULL.
 [2021-01-01 12:17 UTC] shardlow dot a at gmail dot com
You have misunderstood the problem and so your solution does not work. The suggestion of using PREG_UNMATCHED_AS_NULL only changes "" to null in the matches array. The problem remains that an unmatched optional group is not guaranteed to produce a value in the matches array.  I can test for this using isset but this is inelegant and of greater concern is that I am uncertain as to whether there remains a consistent clear mapping between the group order in the pattern and the indices of the matches where present.  With the pattern containing three groups in my example and a value of '1' (which is valid representing just one minute) the match array contains just 3 entries but should contain 4 (the zeroth entry is always the total match).  The first group is optional but IS graced with a null entry.  The last group is optional and IS NOT. If the first group did not produce a null entry the mapping from group order to index would be broken. Hopefully this does not happen. I suspect trailing optional groups fail to generate entries in the matches array.  If the latter the thing is workable (if inelegant) but this should be clearly documented.
 [2021-01-01 14:29 UTC] cmb@php.net
-Status: Not a bug +Status: Open
 [2021-01-01 14:29 UTC] cmb@php.net
Interestingly, basically the same issue had been reported for
preg_match_all() as bug #13635, and has been fixed[1] back then.
I wonder whether the behavioral difference of preg_match() is
intended, or whether that was just overlooked.

At least we need to document that unmatched *trailing*
subpatterns are omitted from the $matches.

[1] <https://github.com/php/php-src/commit/3942e2a8bdf87a40949788df6e2a92ba40acf2ab>
 [2023-06-09 09:05 UTC] hfdifgufojoeui322 at gmail dot com
That was so amazing article I loved that....


More info : - (https://www.ballsportsgear.com/padel-vs-pickleball/)github.com
 [2023-06-15 06:16 UTC] abbieabbott82 at gmail dot com
Thank you so much

(https://pakurangaliquorspot.co.nz/product/ranfurly-draught-cans-in-nz/)php.net
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Nov 21 18:01:29 2024 UTC