Req #55493 [Asn]: Superglobal variable variables with ${expression} in non-global scope

Edit report at https://bugs.php.net/bug.php?id=55493&edit=1 ID: 55493 Updated by: laruence@php.net Reported by: vovan-ve at yandex dot ru Summary: Superglobal variable variables with ${expression} in non-global scope Status: Assigned Type: Feature/Change Request Package: Variables related Operating System: Windows XP SP3 PHP Version: 5.3.7 Assigned To: dmitry Block user comment: N Private report: N New Comment: +1 for dmitry Previous Comments: ------------------------------------------------------------------------ [2011-08-24 13:04:22] dmitry@php.net ZE decides if a variable have to be fetched from the global scope at compile time checking predefined list of super-global variables. The variable fetching by name (e.g. $$name) is always done from local scope. Of course it's possible to extend executor to check for list of super-global variables at run-time, but it'll introduce significant slowdown for each fetch by name. I really don't like it. ------------------------------------------------------------------------ [2011-08-24 12:50:02] laruence@php.net In this case, I make a patch for this, and the test result can be found on: http://pastebin.com/6pTuLEer ------------------------------------------------------------------------ [2011-08-24 12:48:57] laruence@php.net The following patch has been added/updated: Patch Name: bug55493.patch Revision: 1314190137 URL: https://bugs.php.net/patch-display.php?bug=55493&patch=bug55493.patch&revision=1314190137 ------------------------------------------------------------------------ [2011-08-24 10:21:23] vovan-ve at yandex dot ru When I tried to obfuscate a part of code I was surprised by this strange behariour. Of course, current implementation is correct on the one hand. But on the other hand the situation looks funny: this way is allowad, and this too, but this is not. ------------------------------------------------------------------------ [2011-08-24 04:11:14] laruence@php.net sure, it can be fixed by decide target symbol table again in the execution time for not const OPs, but I don't think this is really necessary . :) ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=55493 -- Edit this bug report at https://bugs.php.net/bug.php?id=55493&edit=1