|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2018-04-29 04:59 UTC] requinix@php.net
-Status: Open
+Status: Feedback
-Package: PHP options/info functions
+Package: Scripting Engine problem
[2018-04-29 04:59 UTC] requinix@php.net
[2018-05-03 20:04 UTC] jocrutrisi at ibsats dot com
[2018-06-24 04:25 UTC] php-bugs at lists dot php dot net
[2018-06-24 09:18 UTC] nikic@php.net
-Status: No Feedback
+Status: Re-Opened
[2018-06-24 09:18 UTC] nikic@php.net
[2021-09-13 08:07 UTC] cmb@php.net
-Status: Re-Opened
+Status: Feedback
-Assigned To:
+Assigned To: cmb
[2021-09-13 08:07 UTC] cmb@php.net
[2021-09-26 04:22 UTC] php-bugs at lists dot php dot net
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Fri Oct 24 13:00:02 2025 UTC |
Description: ------------ I was unexpectedly bit by "$_ENV undefined" notice when using auto_globals_jit. Apparently PHP is very specific about what is considered a superglobal use and what isn't. See examples below. Test script: --------------- // This is considered $_ENV use. $foo = $_ENV['foo']; // This is considered $_ENV use. foreach ($_ENV as $k => $v); // BUG: This is NOT considered $_ENV use (so I get a notice here that $_ENV is undefined) $foo = $_ENV; // BUG: Another example of the same problem (I get a notice $_ENV is undefined) function foo() { return ['env' => $_ENV]; } foo(); Expected result: ---------------- I expect JIT should work transparently. Any mention of $_ENV must cause $_ENV to get defined as if it always was. The exceptions are rather odd, it's unclear why detection of use is not fully comprehensive. Actual result: -------------- Notice of undefined $_ENV.