php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #50887 preg_match , last optional sub-patterns ignored when empy
Submitted: 2010-01-30 16:58 UTC Modified: 2010-01-31 11:57 UTC
Votes:12
Avg. Score:4.2 ± 0.8
Reproduced:11 of 11 (100.0%)
Same Version:3 (27.3%)
Same OS:2 (18.2%)
From: harrrrpo at gmail dot com Assigned:
Status: Wont fix Package: PCRE related
PHP Version: 5.3.1 OS: Windows
Private report: No CVE-ID:
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
MUST BE VALID
Solve the problem:
27 - 22 = ?
Subscribe to this entry?

 
 [2010-01-30 16:58 UTC] harrrrpo at gmail dot com
Description:
------------
in preg_match , when optional sub-patterns (using ? or {0,n} ) are the last sub-patterns and empty (e.g. not matched) they are ignored in $matches array
this behavior is inconsistent with preg_match_all , and with the case when the empty optional sub-pattern isn't the last one

Reproduce code:
---------------
$str="1";
preg_match("#\d(\d)?#",$str,$mt);
var_dump($mt);

Expected result:
----------------
array(2) {
  [0]=>
  string(1) "1"
  [1]=>
  string(0) ""
}

(the string(0) "" does appear on all cases with preg_match_all , and with preg_match , when there is any additional sub-patterns after it)

Actual result:
--------------
array(1) {
  [0]=>
  string(1) "1"
}

(the value of sub-pattern vanished)

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-01-31 11:57 UTC] nlopess@php.net
I don't think we can change that behaviour at this point for the sake of not brekaing BC.
 [2011-06-12 01:52 UTC] cappuccino dot e dot cornetto at gmail dot com
I cannot imagine how fixing it would break anything older.

If I expect 3 submatches from my pattern, but I get 2, then I know (for the bug) 
that the missing submatch is the last one and it’s an empty string. So I add it 
myself to the submatches array. Would a programmer do anything different to fix this 
bug?

If the bug is fixed, it means that my old code will always get 3 submatches from 
that pattern. So my own fix won’t get triggered, and having the last submatch the 
same value (empty string) as the one my fix would have added, I won’t have any 
issue, except a bit of (stale) unused code.
 [2011-07-01 07:11 UTC] arveen dot ponniah at loginbn dot ch
hello i'm tamilboy
 [2011-07-13 08:35 UTC] c dot clix at tiscali dot it
This is not a behaviour.
This is a bug, causing occasional and unexpected errors with programs written based on the reference manual.
Fixing the bug will avoid further occasional and unexpected errors.
 [2011-08-03 12:37 UTC] cappuccino dot e dot cornetto at gmail dot com
Delving into a fix for this bug, I found that it's not limited to last optional 
groups but to any last groups. 

In fact, the following:

<code>
$regex = '(?|(Sat)ur(day)|Sun(day)?)';
preg_match("@$regex@", 'Saturday', $matches); print_r($matches);
preg_match("@$regex@", 'Sunday',   $matches); print_r($matches);
preg_match("@$regex@", 'Sun',      $matches); print_r($matches);
</code>

prints:

Array
(
    [0] => Saturday
    [1] => Sat
    [2] => day
)
Array
(
    [0] => Sunday
    [1] => day
)
Array
(
    [0] => Sun
)

While it should print:

Array
(
    [0] => Saturday
    [1] => Sat
    [2] => day
)
Array
(
    [0] => Sunday
    [1] => day
    [2] => 
)
Array
(
    [0] => Sun
    [1] => 
    [2] => 
)
 [2016-04-19 01:04 UTC] c639615 at trbvn dot com
If you can't/won't fix this bug, PLEASE AT LEAST DOCUMENT IT IN THE MANUAL!!!
 
PHP Copyright © 2001-2017 The PHP Group
All rights reserved.
Last updated: Tue Aug 29 15:01:52 2017 UTC