ID: 8794
User Update by: [EMAIL PROTECTED]
Old-Status: Closed
Status: Open
Bug Type: PCRE related
Description: preg_grep changed behavior by design?
The behavior is inconsistent with expectations and breaks code.
In the example given count() returns 1, so loops attempting to access found elements
won't work.
preg_grep() now determines and then discards indexes, forcing the caller
to reconstruct 'valid' indexes (using the count() of the original array and
comparisons to "").
If this is the preferred approach I suggest returning an array of indexes, not a half
baked array of strings.
Previous Comments:
---
[2001-01-19 09:01:51] [EMAIL PROTECTED]
Yes, preg_grep() was always supposed to return the results with their original keys
but it wasn't until the behavior was fixed a little while ago.
---
[2001-01-18 20:27:48] [EMAIL PROTECTED]
?php
# The behavior of preg_grep() changed, seems to be broken.
# Don't know if it is a preg_grep() change or a Zend hash change.
# Indexing bug is my guess, or RedHat 7.0.
# Or maybe by design (see NEWS)
# Here is a test case for reproduction.
# Set up an array of strings.
$a = array( "foo", "bar", "baz" );
# Display them all first, FYI.
for( $bug = 0; $bug count( $a ); $bug++ )
{
echo "test: ".$a[$bug]."br";
}
# This works as expected, [0] is result, [1] is whatever.
$b = preg_grep( "/^foo/", $a );
echo "try to find foo as [0]: ".$b[0]." count=".count( $b )."br";
echo "try to find foo as [1]: ".$b[1]." count=".count( $b )."br";
# This fails as unexpected, [0] is whatever, [1] is result
$b = preg_grep( "/^bar/", $a );
echo "try to find bar as [0]: ".$b[0]." count=".count( $b )."br";
echo "try to find bar as [1]: ".$b[1]." count=".count( $b )."br";
?
---
Full Bug description available at: http://bugs.php.net/?id=8794
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
