PHP 4.0 Bug #8794 Updated: preg_grep changed behavior by design?

From: 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

« previous php.dev (#44549) next »