On Tue, 15 Feb 2005, Andi Gutmans wrote:
This behavior makes some sort of sense. It happens when register_globals is on
which means you are supposed to be able to access $GLOBALS[] and it makes
sense for it to stay in sync with the global variables.
Yes, and register_globals=on is evil. That I do agree with. :)
And that was the initial response I had in mind for this bug report too.
Maybe $GLOBALS[] and $GLOBALS direct access are edge cases but should we
invest time and code to resolve this when we know it's a general problem
anyway?
Well, the patch is there and works with all cases I tried with and could
think of..but I'm all for removing register_globals altogether though. :)
Seriously, this is not consistent (you can't replace e.g. _GET like this)
so why not protect against it?
I cooked up a piece of PHP code to recreate $GLOBALS always when
register_globals=On but come on..it's slow and won't give you exactly
same result..
<?php
/*
* Protect GLOBALS by recreating it whenever register_globals = On
*/
if (ini_get('register_globals')) {
$superglobals = array (
'_SERVER' => $_SERVER,
'_ENV' => $_ENV,
'_FILES' => $_FILES,
'_COOKIE' => $_COOKIE,
'_POST' => $_POST,
'_GET' => $_GET
);
if (isset($_SESSION)) {
array_unshift($superglobals, array ('_SESSION' => $_SESSION));
}
$GLOBALS = array();
foreach ($superglobals as $sg_name => $sg_value) {
$GLOBALS[$sg_name] = $sg_value;
foreach ($sg_value as $name => $value) {
$GLOBALS[$name] = $value;
}
}
}
?>
It lacks the reference to itself of course but who needs that anyway? :)
So, do I post that as resolution for the bug or what?
--Jani
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
