Bug #55650 [NEW]: !empty($_GET[$key][$subkey])) always returns false if $_GET[$key] is set

From: Operating system: Windows 6.1 build 7600 i586 PHP version: 5.3.8 Package: Built-in web server Bug Type: Bug Bug description:!empty($_GET[$key][$subkey])) always returns false if $_GET[$key] is set Description: ------------ Running on PHP Version 5.3.5, EasyPHP Server Apache. The test code on my system shows "SEARCH FILTER PARAM WAS PROVIDED" if ?search=1 is passed for the query string but curiously not if ?search[a]=1 is provided. Based on some other bug reports (#27677) I thought maybe the behavior was correct, but if so then it seems a bug that when _GET is manually set to the same value instead of set by PHP parsing the query string, that it gives different results. So it seems a bug either way. :) Test script: --------------- <?php # Assume http://somesite/?search=1 if (!empty($_GET['search']['filter'])) echo 'SEARCH FILTER PARAM WAS PROVIDED!'; # The REALLY odd thing is if I do this it does give the expected results: $_GET if (!empty($_GET['search']['filter'])) echo 'SEARCH FILTER PARAM WAS NOT PROVIDED!'; <?php # The following (which obviously should be run as a separate script) # demonstrates that the $_GET array seems the same in both cases # It seems like empty() is somehow seeing the _GET array as set by PHP # and the manually set _GET array as different when containing identical # contents! # It seems very odd to me! var_dump($_GET); if (!empty($_GET['search']['filter'])) echo 'SEARCH FILTER PARAM WAS NOT PROVIDED!'; $_GET = array('search'=>1); var_dump($_GET); if (!empty($_GET['search']['filter'])) echo 'SEARCH FILTER PARAM WAS NOT PROVIDED!'; Expected result: ---------------- SEARCH FILTER PARAM WAS PROVIDED if ?search[filter]=1 provided No "SEARCH FILTER PARAM WAS PROVIDED" if ?search=1 Actual result: -------------- SEARCH FILTER PARAM WAS PROVIDED if ?search=1 or ?search[filter]=1 provided -- Edit bug report at https://bugs.php.net/bug.php?id=55650&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55650&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55650&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55650&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55650&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55650&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55650&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55650&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55650&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55650&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55650&r=support Expected behavior: https://bugs.php.net/fix.php?id=55650&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55650&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55650&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55650&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55650&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=55650&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55650&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55650&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55650&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55650&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55650&r=mysqlcfg