Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:14993 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 45867 invoked by uid 1010); 15 Feb 2005 22:27:11 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 45846 invoked from network); 15 Feb 2005 22:27:11 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Feb 2005 22:27:11 -0000 X-Host-Fingerprint: 80.74.107.235 mail.zend.com Linux 2.5 (sometimes 2.4) (4) Received: from ([80.74.107.235:45033] helo=mail.zend.com) by pb1.pair.com (ecelerity 1.2 (r4437)) with SMTP id 58/40-41906-B3772124 for ; Tue, 15 Feb 2005 17:27:11 -0500 Received: (qmail 468 invoked from network); 15 Feb 2005 22:27:04 -0000 Received: from localhost (HELO andi-notebook.zend.com) (127.0.0.1) by localhost with SMTP; 15 Feb 2005 22:27:04 -0000 Message-ID: <5.1.0.14.2.20050215142521.0214d340@localhost> X-Sender: andi@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 15 Feb 2005 14:27:03 -0800 To: Jani Taskinen ,internals@lists.php.net In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [PHP-DEV] [PATCH] Fix for bug #31440 (GLOBALS can be by G/P/C when register_globals=On) From: andi@zend.com (Andi Gutmans) References: 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. 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? Andi At 01:39 PM 2/15/2005 +0200, Jani Taskinen wrote: > Patch to fix is here: > > http://www.php.net/~jani/patches/bug31440.php_4_3_patch > http://www.php.net/~jani/patches/bug31440.php_HEAD_patch > > In PHP_4_3 you can overwrite GLOBALS with these queries: > > ?GLOBALS[foo]=err or ?GLOBALS[]=foo or ?GLOBALS=foo > > In HEAD you can overwrite GLOBALS with this only: > > ?GLOBALS=foo > > I didn't investigate WHY that is the only type of query that > "works" in HEAD branch but the same patch fixed that too. > > None of super-globals can be overwritten like this, be it > register_globals On or Off. > > IMNSHO, GLOBALS should be "protected". > (I don't say that this hacky patch of mine is the way, but it does > the job :) > > --Jani > >-- >PHP Internals - PHP Runtime Development Mailing List >To unsubscribe, visit: http://www.php.net/unsub.php