ID:               36983
 Updated by:       [EMAIL PROTECTED]
 Reported By:      crisp at tweakers dot net
 Status:           Bogus
 Bug Type:         PCRE related
 Operating System: all
 PHP Version:      4.4.2
 New Comment:

"Bogus" doesn't mean "reporter is an idiot, the bug exists only in his
imagination".
"Bogus" quite often means "there were no issue we can fix, so we can't
CLOSE it (i.e. FIX), we can only mark it as BOGUS (i.e. not PHP
problem)".
Status "CLOSED" means there was a bug in PHP itself and it was fixed.
This is not the case. Nothing personal whatsoever.

PCRE category exists for quite obvious reason: PHP functions in
ext/pcre may be buggy, so you should be able to report problems in this
category.

Yes, we could of course add some more statuses like "not PHP problem",
"RTFM", "floats have limited precision" or "please copy libmysql.dll to
$PATH", but well.. does it make any sense? Not to me.


Previous Comments:
------------------------------------------------------------------------

[2006-04-05 19:52:12] crisp at tweakers dot net

Not to be disrespectfull but honestly I feel a bit put off by the reply
I'm getting here. When I personally put time in creating a valid and
easy to follow testcase and submit it here, believing this is the right
place to go (I found this bug using a PHP built-in function and it is
PCRE related - why else do you have that category?) and by doing so
helping in improving PHP, and all I'm getting is a 'this bug is
bogus'-reply when it formally isn't.

Maybe you should consider some more status codes like '3rd party
related' or so - at least something that doesn't have such a negative
sound and that actually reflects the status of the bugreport.

And even when such an issue is 3rd party related I would think the PHP
development team should at least feel some responsibility or show some
concern about such issues. You probably have better contacts with these
parties than I do and it is in your benefit too that such issues get
resolved.

Thank you in advance for making me think twice about submitting a bug
the next time I encounter one; it'll probably save me some time...

------------------------------------------------------------------------

[2006-04-05 17:40:05] [EMAIL PROTECTED]

This is PHP bug system and issues that do not belong here are bogus.

------------------------------------------------------------------------

[2006-04-05 17:25:11] crisp at tweakers dot net

Indeed this seems to be an issue with PCRE; version 6.6 still has this
problem so I'll try my luck with the PCRE team.
Notwithstanding I don't believe 'bogus' is the right status for this
bug since it is an actual issue, just not with PHP (although afaik PHP
still ships with PCRE version 6.4).
I'll just put this bug to 'closed'

------------------------------------------------------------------------

[2006-04-05 14:36:06] [EMAIL PROTECTED]

If there is a problem, it is PCRELib problem.
Please report it to PCRELib developers.

------------------------------------------------------------------------

[2006-04-05 12:41:15] crisp at tweakers dot net

Description:
------------
It seems that when PCRE needs to backtrack more than 20 characters in
order to evaluate an OR'ed expression the results of a preg_match_all
are incorrect/incomplete.
See below code as an example.

Reproduce code:
---------------
$foo = 'foo# bar# abcdefghijklmnopqrst bla#';
echo '$foo = ', $foo, "\n";

preg_match_all('/([a-y]|z)+#/', $foo, $matches1);
preg_match_all('/([a-y]+|z)+#/', $foo, $matches2);

print_r($matches1[0]);
print_r($matches2[0]);


$foo = 'foo# bar# abcdefghijklmnopqrstu bla#';
echo '$foo = ', $foo, "\n";

preg_match_all('/([a-y]|z)+#/', $foo, $matches1);
preg_match_all('/([a-y]+|z)+#/', $foo, $matches2);

print_r($matches1[0]);
print_r($matches2[0]);


Expected result:
----------------
both expressions for both strings should give the following output:

Array
(
    [0] => foo#
    [1] => bar#
    [2] => bla#
)

Actual result:
--------------
The last expression gives the following output on the last string:

Array
(
    [0] => foo#
    [1] => bar#
)

The last match on bla# is missing in the result for the preg_match_all


------------------------------------------------------------------------


-- 
Edit this bug report at http://bugs.php.net/?id=36983&edit=1

Reply via email to