PHP 4.0 Bug #8794 Updated: preg_grep changed behavior by design?
| From: | andrei@php.net | Date: | Fri, 19 Jan 2001 14:01:51 +0000 |
| Subject: | PHP 4.0 Bug #8794 Updated: preg_grep changed behavior by design? | ||
| Groups: | php.dev | ||
| Request: | Send a blank email to php-dev+get-44549@lists.php.net to get a copy of this message | ||
ID: 8794
Updated by: andrei
Reported By: instigator@openave.com
Old-Status: Open
Status: Closed
Bug Type: PCRE related
Assigned To:
Comments:
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.
Previous Comments:
---------------------------------------------------------------------------
[2001-01-18 20:27:48] instigator@openave.com
<?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