Req #63818 [Com]: Need option to search in array keys instead of values
Edit report at https://bugs.php.net/bug.php?id=63818&edit=1
ID: 63818
Comment by: danielklein at airpost dot net
Reported by:dkadosh at affinegy dot com
Summary:Need option to search in array keys instead of
values
Status: Open
Type: Feature/Change Request
Package:PCRE related
Operating System: any
PHP Version:5.3.20
Block user comment: N
Private report: N
New Comment:
How about this?
Previous Comments:
[2012-12-20 17:06:30] dkadosh at affinegy dot com
Description:
---
>From manual page: http://www.php.net/function.preg-grep
---
I'm asking for an extra flag to this function, to cause it to do its search in
the array keys rather than in the values.
While there's a comment in the above page of how to "post-process" preg_grep()
results to achieve this, I'd rather it be done in C (inside the PCRE code) than
PHP for performance reasons.
I thought about something like this:
$a = array_flip( preg_grep('/Version$/', array_flip($aParams)) );
which would almost return what I want, HOWEVER it has two problems:
1) If certain values of $aParams are duplicated, the first array_flip() will
"lose" those rows in the array.
2) I'd incur a sizeable CPU and memory hit by calling array_flip, which
duplicates the array(s) in RAM.
Test script:
---
The current work-around:
function preg_grep_keys( $pattern, $input, $flags = 0 )
{
$keys = preg_grep( $pattern, array_keys( $input ), $flags );
$vals = array();
foreach ( $keys as $key )
{
$vals[$key] = $input[$key];
}
return $vals;
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=63818&edit=1
Req #63284 [Csd]: Please upgrade PCRE
Edit report at https://bugs.php.net/bug.php?id=63284&edit=1 ID: 63284 User updated by:danielklein at airpost dot net Reported by:danielklein at airpost dot net Summary:Please upgrade PCRE Status: Closed Type: Feature/Change Request Package:PCRE related PHP Version:5.4.7 Assigned To:ab Block user comment: N Private report: N New Comment: Thanks ab. Are you monitoring this at the moment? It seems silly to raise a new request for every version of PCRE if someone is already taking care of it. Previous Comments: [2013-03-13 09:02:04] a...@php.net pcre 8.32 was merged a few weeks ago ) [2012-12-20 23:46:04] danielklein at airpost dot net Good news Nicolas! I'm assuming this will need another change request to make it into a future version of PHP. [2012-12-20 14:07:23] nicolas dot grekas+php at gmail dot com Version 8.32 is out ! http://vcs.pcre.org/viewvc/code/tags/pcre-8.32/ [2012-10-19 08:34:14] a...@php.net Thanks for testing ) @danielklein Theoretically it can be done, depends how much of other things one has on the plate right now. If you're highly interested having the newest PCRE, monitor it and do requests - later or sooner they'll be taken on ) [2012-10-19 08:05:56] a...@php.net Automatic comment on behalf of ab Revision: http://git.php.net/?p=php-src.git;a=commit;h=276c5de0d86abab52a19f489dd74565fdec0d3ca Log: Fixed bug #63284 PCRE upgrade to 8.31 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=63284 -- Edit this bug report at https://bugs.php.net/bug.php?id=63284&edit=1
Bug #61018 [Com]: Unexplained bool(false) returned from preg_match
Edit report at https://bugs.php.net/bug.php?id=61018&edit=1 ID: 61018 Comment by: danielklein at airpost dot net Reported by:dey101+php at gmail dot com Summary:Unexplained bool(false) returned from preg_match Status: Open Type: Bug Package:PCRE related PHP Version:5.3.10 Block user comment: N Private report: N New Comment: I have simplified the error to the following: Outputs: boolean false int 0 Saying /(\w*)*/ is VERY inefficient as it must try every combination before failing, i.e. matching: 'ABCDEFGHIJ12345678', '' 'ABCDEFGHIJ1234567', '8', '' 'ABCDEFGHIJ1234567', '', '8', '' 'ABCDEFGHIJ123456', '78', '' 'ABCDEFGHIJ123456', '7', '8', '' 'ABCDEFGHIJ123456', '7', '', '8', '' 'ABCDEFGHIJ123456', '', '78', '' ... '', 'A', '', 'B', '', 'C', '', 'D', '', 'E', '', 'F', '', 'G', '', 'H', '', 'I', '', 'J', '', '1', '', '2', '', '3', '', '4', '', '5', '', '6', '', '7', '', '8', '' It is most likely running out of memory before it completes. I would suggest that this is not a bug as it will use exponentially more memory the longer the input string gets. You should try something like '/^(?:(?>\w*))*$/i' instead to avoid undesired backtracking. Previous Comments: [2012-02-15 18:39:27] mattfic...@php.net I have verified that the output from this repro script is the same on both Windows and Linux (Both using 5.3.10), so this is not a Windows specific bug report anymore. [2012-02-14 13:42:21] dey101+php at gmail dot com I did not have access to a linux test platform to test. If you have verified that the bug exists on multiple platforms, please fee free to re-classify as a general bug. [2012-02-13 23:40:06] mattfic...@php.net Thank you for your report and helping to make php better. When I ran your script on Windows 2008 and Linux(using TS build of php5.3.10), it looks like the output is the same on both OSes. I don't think this is a PHP on Windows bug. If you would like, I can reclassify this bug as a general bug, not specific to Windows. Or, am I missing something? Is this really a PHP on Windows problem? win2008 sp1 x64 output(TS Build): Regex: /^[[:alnum:]](?:[[:alnum:]\-]*[[:alnum:]])*$/ Host: ABCDEFGHIJ1234567890. Result: (error) bool(false) Host: ABCDEFGHI234567890. Result: (no match) int(0) Host: ABCDEFGHIJ1234567890 Result: (match) int(1) Host: ABCDEFGHI1234567890 Result: (match) int(1) Host: ABCDEFGHI123456789 Result: (match) int(1) Host: ABCDEFGHIJ-1234567890 Result: (match) int(1) Host: ABCDEFGHIJ-123456789 Result: (match) int(1) Host: ABCDEFGHI-123456789 Result: (match) int(1) Host: WWW.ABCDEFGHIJ-1234567890.COM Result: (no match) int(0) Host: WWW.SUB-SUBDOMAIN.SUBDOMAIN.ABCD-EFGH-IJKL-MNOP-QRST-UVWX-YZ-12345-67890 -abcd-efgh-hijk.COM Result: (no match) int(0) Regex: /^(?:[[:alnum:]](?:[[:alnum:]\-]*[[:alnum:]])*\.)*$/ Host: ABCDEFGHIJ1234567890. Result: (match) int(1) Host: ABCDEFGHI234567890. Result: (match) int(1) Host: ABCDEFGHIJ1234567890 Result: (error) bool(false) Host: ABCDEFGHI1234567890 Result: (error) bool(false) Host: ABCDEFGHI123456789 Result: (no match) int(0) Host: ABCDEFGHIJ-1234567890 Result: (error) bool(false) Host: ABCDEFGHIJ-123456789 Result: (error) bool(false) Host: ABCDEFGHI-123456789 Result: (no match) int(0) Host: WWW.ABCDEFGHIJ-1234567890.COM Result: (error) bool(false) Host: WWW.SUB-SUBDOMAIN.SUBDOMAIN.ABCD-EFGH-IJKL-MNOP-QRST-UVWX-YZ-12345-67890 -abcd-efgh-hijk.COM Result: (error) bool(false) Regex: /^(?:[[:alnum:]](?:[[:alnum:]\-]*[[:alnum:]])*\.)+$/ Host: ABCDEFGHIJ1234567890. Result: (match) int(1) Host: ABCDEFGHI234567890. Result: (match) int(1) Host: ABCDEFGHIJ1234567890 Result: (no match) int(0) Host: ABCDEFGHI1234567890 Result: (no match) int(0) Host: ABCDEFGHI123456789 Result: (no match) int(0) Host: ABCDEFGHIJ-1234567890 Result: (no match) int(0) Host: ABCDEFGHIJ-123456789 Result: (no match) int(0) Host: ABCDEFGHI-1234567
Req #54223 [Com]: enhance / change newline behavior
Edit report at https://bugs.php.net/bug.php?id=54223&edit=1
ID: 54223
Comment by: danielklein at airpost dot net
Reported by:carsten_sttgt at gmx dot de
Summary:enhance / change newline behavior
Status: Open
Type: Feature/Change Request
Package:PCRE related
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
This is very old, well defined behaviour.
/$/ matches /(?=\n?(?![\w\W]))/, that is a just before a newline with no
remaining characters or end-of-string (no more characters). What you are asking
for is /(?=\r?\n?(?![\w\W]))/ (or /$/m => /(?=\r\n?|\n)/) unless you're asking
for ONLY \r\n to match! This would also have to change the meaning of /./
(without /s) from /[^\n]/ to /[^\r\n]/. This would be confusing for people used
to the old way of doing things. Would this mean that /^/m would match just
after a \r? (but not in between a \r and a \n???)
It would be better to specify what you are matching or not matching rather than
changing the behaviour of carriage returns. I agree this can make regexes more
difficult to write and understand in some instances but I would vote to stay
with the status quo as I believe adding such an option would add to the total
confusion rather than decrease it. If you write /[^\r\n]+/ it is perfectly
clear to anyone who understands character classes. Note that the difference
between /.+/ and /.+/s is already subtle and easily missed.
Another alternative is str_replace("\r\n", "\n", $input) before using the regex
which will convert Windows style line endings to Unix style line endings.
Previous Comments:
[2011-03-11 11:23:30] carsten_sttgt at gmx dot de
Description:
At the moment (PHP bundled) PCRE is build with the default "#define NEWLINE 10".
As a result "$" means "\n" but not e.g. "\r\n" and "\r" remains as part of the
match. This is unexpected for some people, especially on Windows. See the
example below.
There are 3 solutions:
1)
Building PCRE with "#define NEWLINE -2", or with "#define NEWLINE -1" (because
PCRE is still build with Unicode support)
2)
Adding a INI option like "pcre.newline=any"
3)
Making PCRE_NEWLINE_ANY, PCRE_NEWLINE_CR, PCRE_NEWLINE_CRLF, PCRE_NEWLINE_LF
available to the userland (maybe as pattern modifier), like you can do this
with C using the PCRE library.
(Well, 1) is not essential if 2) and 3) is available)
Test script:
---
Expected result:
array(1) {
[0]=>
array(3) {
[0]=>
string(5) "line1"
[1]=>
string(5) "line2"
[2]=>
string(5) "line3"
}
}
Actual result:
--
array(1) {
[0]=>
array(3) {
[0]=>
" string(6) "line1
[1]=>
" string(6) "line2
[2]=>
" string(6) "line3
}
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=54223&edit=1
Req #62614 [Opn]: Please update PCRE library to latest version
Edit report at https://bugs.php.net/bug.php?id=62614&edit=1 ID: 62614 User updated by:danielklein at airpost dot net Reported by:danielklein at airpost dot net Summary:Please update PCRE library to latest version Status: Open Type: Feature/Change Request Package:PCRE related -PHP Version:5.4.5 +PHP Version:5.4.9 Block user comment: N Private report: N New Comment: Thank you to all the people who helped get PCRE 8.31 into PHP 5.4.9 (& 5.3.19)! Now that PCRE 8.32 has been released, can that make its way into PHP too please? Main improvement (from user comments on previous request) - \X matches a Unicode extended grapheme cluster Thank you again! Previous Comments: [2012-07-20 00:20:57] danielklein at airpost dot net Description: PCRE Library Version is 8.12 (15-Jan-2011) as of PHP 5.4.5 (18-Jul-2012). Latest PCRE Library Version is 8.30 (04-Feb-2012). Please update PHP as there have been many improvements. -- Edit this bug report at https://bugs.php.net/bug.php?id=62614&edit=1
Req #63284 [Csd]: Please upgrade PCRE
Edit report at https://bugs.php.net/bug.php?id=63284&edit=1 ID: 63284 User updated by:danielklein at airpost dot net Reported by:danielklein at airpost dot net Summary:Please upgrade PCRE Status: Closed Type: Feature/Change Request Package:PCRE related PHP Version:5.4.7 Assigned To:ab Block user comment: N Private report: N New Comment: Good news Nicolas! I'm assuming this will need another change request to make it into a future version of PHP. Previous Comments: [2012-12-20 14:07:23] nicolas dot grekas+php at gmail dot com Version 8.32 is out ! http://vcs.pcre.org/viewvc/code/tags/pcre-8.32/ [2012-10-19 08:34:14] a...@php.net Thanks for testing ) @danielklein Theoretically it can be done, depends how much of other things one has on the plate right now. If you're highly interested having the newest PCRE, monitor it and do requests - later or sooner they'll be taken on ) [2012-10-19 08:05:56] a...@php.net Automatic comment on behalf of ab Revision: http://git.php.net/?p=php-src.git;a=commit;h=276c5de0d86abab52a19f489dd74565fdec0d3ca Log: Fixed bug #63284 PCRE upgrade to 8.31 [2012-10-19 01:32:42] mattfic...@php.net I built PHP_5_4 (newest snapshot) with your patch. I tested it with all the PHPTs (all, including the PCRE tests) and all the PHPUnit tests from Joomla and found no regressions. I got no additional test failures after I applied your patch. [2012-10-18 23:43:17] danielklein at airpost dot net Can the latest PCRE be included in PHP every time it's released? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=63284 -- Edit this bug report at https://bugs.php.net/bug.php?id=63284&edit=1
Req #63284 [Asn]: Please upgrade PCRE
Edit report at https://bugs.php.net/bug.php?id=63284&edit=1 ID: 63284 User updated by:danielklein at airpost dot net Reported by:danielklein at airpost dot net Summary:Please upgrade PCRE Status: Assigned Type: Feature/Change Request Package:PCRE related PHP Version:5.4.7 Assigned To:ab Block user comment: N Private report: N New Comment: Can the latest PCRE be included in PHP every time it's released? Previous Comments: [2012-10-18 14:44:12] a...@php.net Well, if you look at the PCRE release frequency, it vary from one month to one year. 8.32 will surely come some when :) [2012-10-18 12:33:26] nicolas dot grekas+php at gmail dot com This is a good idea! Could we wait just a little for 8.32 to be released? 8.32 will support Unicode Extended Grapheme Clusters with \X and I think this is good for PHP's unicode support. see http://bugs.exim.org/show_bug.cgi?id=1279 [2012-10-18 10:14:28] a...@php.net Please try the patch from here http://belsky.info/phpz/bugz/63297/pcre-8.31.patch.gz Tested all the permutations of linux/windows 5.3/5.4/master ts/nts and all the PCRE tests pass for me. Note that config.m4 and config.w32 was changed, so buildconf --force is needed for this to be compiled correctly. [2012-10-16 06:11:36] danielklein at airpost dot net Description: Please upgrade PCRE. Version 8.12 is very old (15-Jan-2011). Current version is 8.31 (06-July-2012). -- Edit this bug report at https://bugs.php.net/bug.php?id=63284&edit=1
[PHP-BUG] Req #63284 [NEW]: Please upgrade PCRE
From: danielklein at airpost dot net Operating system: PHP version: 5.4.7 Package: PCRE related Bug Type: Feature/Change Request Bug description:Please upgrade PCRE Description: Please upgrade PCRE. Version 8.12 is very old (15-Jan-2011). Current version is 8.31 (06-July-2012). -- Edit bug report at https://bugs.php.net/bug.php?id=63284&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63284&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63284&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63284&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63284&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63284&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63284&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63284&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63284&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63284&r=support Expected behavior: https://bugs.php.net/fix.php?id=63284&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63284&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63284&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63284&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63284&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63284&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63284&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63284&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63284&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63284&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63284&r=mysqlcfg
[PHP-BUG] Req #62614 [NEW]: Please update PCRE library to latest version
From: danielklein at airpost dot net Operating system: PHP version: 5.4.5 Package: PCRE related Bug Type: Feature/Change Request Bug description:Please update PCRE library to latest version Description: PCRE Library Version is 8.12 (15-Jan-2011) as of PHP 5.4.5 (18-Jul-2012). Latest PCRE Library Version is 8.30 (04-Feb-2012). Please update PHP as there have been many improvements. -- Edit bug report at https://bugs.php.net/bug.php?id=62614&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62614&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62614&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62614&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62614&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62614&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62614&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62614&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62614&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62614&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62614&r=support Expected behavior: https://bugs.php.net/fix.php?id=62614&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62614&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62614&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62614&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62614&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62614&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62614&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62614&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62614&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62614&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62614&r=mysqlcfg
Bug #62427 [Nab]: PCRE invalid "\k" sequence does not cause warning or error
Edit report at https://bugs.php.net/bug.php?id=62427&edit=1
ID: 62427
User updated by:danielklein at airpost dot net
Reported by:danielklein at airpost dot net
Summary:PCRE invalid "\k" sequence does not cause warning or
error
Status: Not a bug
Type: Bug
Package:PCRE related
PHP Version:5.4.4
Block user comment: N
Private report: N
New Comment:
I see... PHP 5.4.4 is using PCRE 8.12 (according to my phpinfo();) This
particular bug was fixed in PCRE 8.13 :( Missed it by >that< much...
http://pcre.org/changelog.txt - Search for \k
Can PHP be updated to use the latest PCRE?
P.S. I thought you were only allowed to report issues against the current
version of PHP? PCRE 8.02 was included in PHP 5.3.3 :p
P.P.S. The documentation is out of date on the following page:
http://www.php.net/manual/en/pcre.installation.php
Previous Comments:
[2012-06-27 13:16:00] fel...@php.net
Not a PHP bug. The error depends on the PCRE library version.
$ pcretest
PCRE version 8.02 2010-03-19
re> /\k/
data> a
No match
re> /\g/
Failed: a numbered reference must not be zero at offset 1
[2012-06-27 03:13:13] ras...@php.net
For reference, the command pcretest tool that comes with PCRE-8.30 gives this:
re> /\k/
Failed: \k is not followed by a braced, angle-bracketed, or quoted name at
offset
2
re> /\g/
Failed: a numbered reference must not be zero at offset 1
----
[2012-06-27 01:22:24] danielklein at airpost dot net
Description:
The "\k" escape must be followed by 'name', or {name}. A PCRE regex that
contains "\k" without the properly quoted name will compile without an error
and will always fail as "\k" can never (as far as I know) match anything in the
subject string. It is almost identical to "\g", except "\g" also allows "\gn",
"\g{n}" or "\g{-n}" where "n" is any positive decimal number.
I have been unable to test PCRE directly (i.e. via the command line, not
through PHP) as I can't compile it on my computer. I have looked through the
source code and the test results, and from that it seems to be working
correctly. Although I'm not 100% sure, I think this bug is specific to PHP.
Test script:
---
Expected result:
Warning: preg_match(): Compilation failed: **something about name missing in \k
back-reference** at offset 1 in test.php on line 3
bool(false)
Warning: preg_match(): Compilation failed: a numbered reference must not be
zero at offset 1 in test.php on line 3
bool(false)
Actual result:
--
int(0)
Warning: preg_match(): Compilation failed: a numbered reference must not be
zero at offset 1 in test.php on line 3
bool(false)
--
Edit this bug report at https://bugs.php.net/bug.php?id=62427&edit=1
[PHP-BUG] Bug #62427 [NEW]: PCRE invalid "\k" sequence does not cause warning or error
From: danielklein at airpost dot net
Operating system:
PHP version: 5.4.4
Package: PCRE related
Bug Type: Bug
Bug description:PCRE invalid "\k" sequence does not cause warning or error
Description:
The "\k" escape must be followed by 'name', or {name}. A PCRE regex
that contains "\k" without the properly quoted name will compile without an
error and will always fail as "\k" can never (as far as I know) match
anything in the subject string. It is almost identical to "\g", except "\g"
also allows "\gn", "\g{n}" or "\g{-n}" where "n" is any positive decimal
number.
I have been unable to test PCRE directly (i.e. via the command line, not
through PHP) as I can't compile it on my computer. I have looked through
the source code and the test results, and from that it seems to be working
correctly. Although I'm not 100% sure, I think this bug is specific to PHP.
Test script:
---
Expected result:
Warning: preg_match(): Compilation failed: **something about name missing
in \k back-reference** at offset 1 in test.php on line 3
bool(false)
Warning: preg_match(): Compilation failed: a numbered reference must not be
zero at offset 1 in test.php on line 3
bool(false)
Actual result:
--
int(0)
Warning: preg_match(): Compilation failed: a numbered reference must not be
zero at offset 1 in test.php on line 3
bool(false)
--
Edit bug report at https://bugs.php.net/bug.php?id=62427&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62427&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62427&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62427&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62427&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62427&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62427&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62427&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62427&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62427&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62427&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62427&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62427&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62427&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62427&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62427&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62427&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62427&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62427&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62427&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62427&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62427&r=mysqlcfg
[PHP-BUG] Bug #61780 [NEW]: Inconsistent PCRE captures in match results
From:
Operating system:
PHP version: 5.4.0
Package: PCRE related
Bug Type: Bug
Bug description:Inconsistent PCRE captures in match results
Description:
Named and unnamed captures in both preg_match and preg_match_all (and
probably preg_replace and the other PCRE functions too but I haven't tested
them all) can capture the wrong number of parentheses if alternation or a
zero-or-more quantifier is used.
If the pattern '/(?b)|(?c)|(?d)/' is used to match 'c', both 'b'
and 'c' will be set in the results array but 'd' won't be. 'b' should not
be set (even to an empty string) as it failed to match anything. However,
if it was trying to match '/(?b?)(?c)/' (note: optional 'b' AND
mandatory 'c'), 'b' _should_ be set to '' as it's allowed to match a
zero-length string. If a match gets tried but it fails and a capture later
in the pattern works, the skipped capture should never produce a key in the
results array. It should be OK to leave holes in the numbered sequence
(e.g. match 0 and 2 but not 1).
Currently, you need to use PREG_OFFSET_CAPTURE and test to see if the key
exists, and if it does, test to see if the capture position is -1. If this
bug is fixed, capture positions will never be -1 as the key won't exist.
Alternatively, an additional flag could be added (e.g.
PREG_KEEP_NONMATCHES) to create keys for ALL captures whether used or not
(so, in the first pattern above, keys would be created for 'b', 'c' and 'd'
in all cases, and if matching the string 'c' the offsets for both 'b' and
'd' would be -1).
In summary, if the pattern '/(?b)|(?c)|(?d)/' is used to match
'c', by default it should only ever create a key for 'c'. If desired, an
additional flag could be added so that it creates keys for all captures:
'b', 'c' and 'd'. The current behaviour where it creates a key for 'b' and
'c' but not 'd' should be considered a bug and fixed.
Test script:
---
print('');
$offset = 0;
while (preg_match('/(?:(?b)|(?c)|(?d))(?e)?/', 'cdec',
$matches, PREG_OFFSET_CAPTURE, $offset)) {
$offset = $matches[0][1] + strlen($matches[0][0]);
var_export($matches);
print("\n\n");
}
print("\n\n");
preg_match_all('/(?:(?b)|(?c)|(?d))(?e)?/', 'cdec', $matches,
PREG_OFFSET_CAPTURE | PREG_SET_ORDER);
var_export($matches);
print('');
Expected result:
array (
0 =>
array (
0 => 'c',
1 => 0,
),
'c' =>
array (
0 => 'c',
1 => 0,
),
2 =>
array (
0 => 'c',
1 => 0,
),
)
array (
0 =>
array (
0 => 'de',
1 => 1,
),
'd' =>
array (
0 => 'd',
1 => 1,
),
3 =>
array (
0 => 'd',
1 => 1,
),
'e' =>
array (
0 => 'e',
1 => 2,
),
4 =>
array (
0 => 'e',
1 => 2,
),
)
array (
0 =>
array (
0 => 'c',
1 => 3,
),
'c' =>
array (
0 => 'c',
1 => 3,
),
2 =>
array (
0 => 'c',
1 => 3,
),
)
array (
0 =>
array (
0 =>
array (
0 => 'c',
1 => 0,
),
'c' =>
array (
0 => 'c',
1 => 0,
),
2 =>
array (
0 => 'c',
1 => 0,
),
),
1 =>
array (
0 =>
array (
0 => 'de',
1 => 1,
),
'd' =>
array (
0 => 'd',
1 => 1,
),
3 =>
array (
0 => 'd',
1 => 1,
),
'e' =>
array (
0 => 'e',
1 => 2,
),
4 =>
array (
0 => 'e',
1 => 2,
),
),
2 =>
array (
0 =>
array (
0 => 'c',
1 => 3,
),
'c' =>
array (
0 => 'c',
1 => 3,
),
2 =>
array (
0 => 'c',
1 => 3,
),
),
)
Actual result:
--
array (
0 =>
array (
0 => 'c',
1 => 0,
),
'b' =>
array (
0 => '',
1 => -1,
),
1 =>
array (
0 => '',
1 => -1,
),
'c' =>
array (
0 => 'c',
1 => 0,
),
2 =>
array (
0 => 'c',
1 => 0,
),
)
array (
0 =>
array (
0 => 'de',
1 => 1,
),
'b' =>
array (
0 => '',
1 => -1,
),
1 =>
array (
0 => '',
1 => -1,
),
'c' =>
array (
0 => '',
1 => -1,
),
2 =>
array (
0 => '',
1 => -1,
),
'd' =>
array (
0 => 'd',
1 => 1,
),
3 =>
array (
0 => 'd',
1 => 1,
),
'e' =>
array (
0 => 'e',
1 => 2,
),
4 =>
array (
0 => 'e',
1 => 2,
),
)
array (
0 =>
array (
0 => 'c',
1 => 3,
),
'b' =>
array (
0 => '',
1 => -1,
),
1 =>
array (
0 => '',
1 => -1,
),
'c' =>
array (
0 => 'c',
1 => 3,
),
2 =>
array (
0 => 'c',
1 => 3,
),
)
array (
0 =>
array (
0 =>
array (
0 => 'c',
1 => 0,
),
'b' =>
array (
0 => '',
1 => -1,
),
1 =>
array (
0 => '',
1 => -1,
),
'c' =>
array (
0 => 'c',
1 => 0,
),
