When releasing 4.0.6 I noticed this change (I didn't take active part in
the discussion). Can someone bring me up to speed as to:
(a) Why was it impossible to write portable code with register_globals
being off
(b) Why does it make sense to have $HTTP_SESSION_GLOBALS behave in an
inconsistentl
> > Aha. This caused some really bad 'bugs' in the new PHP release...
> > I didn't know why it was bad... Please revert to the same method
> > as $HTTP_*_VARS use...
>
> Excuse me? I'm quite confused by your message. Do you mean that
> $HTTP_SESSION_VARS['foo'] and $foo should not be references t
On Tue, 22 May 2001, Hojtsy Gabor wrote:
> Aha. This caused some really bad 'bugs' in the new PHP release...
> I didn't know why it was bad... Please revert to the same method
> as $HTTP_*_VARS use...
Excuse me? I'm quite confused by your message. Do you mean that
$HTTP_SESSION_VARS['foo'] and $f
> > > >As I mentioned in my other message, $HTTP_SESSION_VARS value and the
> > > >global value used to be references, but after some people complained
> > > >about this fact on the list, it was changed.. I wouldn't mind
> > > >reinstating it, but if we do, let's do it once and for all with very
>
PROTECTED]
>Subject: Re: [PHP-DEV] Using $HTTP_SESSION_VARS with register_globals On
>Mail-Followup-To: Andrei Zmievski <[EMAIL PROTECTED]>,
> Andi Gutmans <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
> [EMAIL PROTECTED], [EMAIL PROTECTED]
>User-Agent: Mutt/1.2.5i
> That approach gets my vote, too. As one who has lived through
> scoping hell along with Chuck, I'm all for making this part of
> PHP friendlier and, at the very least, more consistent.
Ok, it's done.
-Andrei
The 3 great virtues of a programmer:
Laziness, Impatience, and Hubris.
On Tue, 22 May 2001, Andi Gutmans wrote:
> >As I mentioned in my other message, $HTTP_SESSION_VARS value and the
> >global value used to be references, but after some people complained
> >about this fact on the list, it was changed.. I wouldn't mind
> >reinstating it, but if we do, let's do it onc
At 05:02 PM 5/21/2001 -0500, Andrei Zmievski wrote:
>On Mon, 21 May 2001, [EMAIL PROTECTED] wrote:
> > I guess logically we should make the global variable take precedence and
> > perhaps even export any changes to $HTTP_SESSION_VARS into the global
> > symbol table. Somewhat magical, but what el
On Mon, 21 May 2001, Jon Parise wrote:
> That approach gets my vote, too. As one who has lived through
> scoping hell along with Chuck, I'm all for making this part of
> PHP friendlier and, at the very least, more consistent.
Maybe you could take it upon yourself to send a brief message to
php-g
On Mon, May 21, 2001 at 05:02:03PM -0500, Andrei Zmievski wrote:
> > I guess logically we should make the global variable take precedence and
> > perhaps even export any changes to $HTTP_SESSION_VARS into the global
> > symbol table. Somewhat magical, but what else can we do here? I really
> >
On Mon, 21 May 2001, [EMAIL PROTECTED] wrote:
> I guess logically we should make the global variable take precedence and
> perhaps even export any changes to $HTTP_SESSION_VARS into the global
> symbol table. Somewhat magical, but what else can we do here? I really
> don't think we can live with
Quoting Andrei Zmievski <[EMAIL PROTECTED]>:
> Can't please everybody, eh?
Of course not. But I think it's pretty bad that code written to work with
register_globals = Off breaks when its turned on; it kind of fucks the idea of
writing general php code that people can run anywhere, if you'll p
> On Mon, 21 May 2001, [EMAIL PROTECTED] wrote:
> > Yes, I figured that was the issue. If $HTTP_SESSION_VARS is set then I
> > think it should take precedence. I think the current approach where
> > scripts written with register_globals set to Off do not work on servers
> > that have register_gl
On Mon, 21 May 2001, Chuck Hagenbuch wrote:
> Something about people not expecting the values to be references to each other,
> if I remember. Which is the opposite of the current unintuitive behavior.
Can't please everybody, eh?
-Andrei
* "Lack of planning on your part doesn't constitute an em
Quoting Andrei Zmievski <[EMAIL PROTECTED]>:
> I think it used to be that both of them referenced the same value, but
> it was changed due to some memorably big discussion the cause of which I
> fail to remember at this point..
Something about people not expecting the values to be references to
On Mon, 21 May 2001, Chuck Hagenbuch wrote:
> No, it's not. The other option is, if register_globals is on, to make $foo and
> $HTTP_SESSION_VARS['foo'] references pointing to the same value (well, one
> points to the other; I don't _think_ it matters which).
>
> However it's solved, it'd be _r
Quoting Andrei Zmievski <[EMAIL PROTECTED]>:
> How about this scenario -- register_globals is on, session is loaded,
> $HTTP_SESSION_VARS['foo'] and $foo contain the same value, then user
> changes $foo, thinking it will be saved. But if you say
> $HTTP_SESSION_VARS value takes precedence, then h
On Mon, 21 May 2001, [EMAIL PROTECTED] wrote:
> Yes, I figured that was the issue. If $HTTP_SESSION_VARS is set then I
> think it should take precedence. I think the current approach where
> scripts written with register_globals set to Off do not work on servers
> that have register_globals On i
> On Mon, 21 May 2001, Rasmus Lerdorf wrote:
> > Looks like this code in session.c is the culprit:
> >
> > int php_get_session_var(char *name, size_t namelen, zval ***state_var PLS_DC
>PSLS_DC ELS_DC)
> > {
> > HashTable *ht = &EG(symbol_table);
> >
> > if (!PG(register_globals))
On Mon, 21 May 2001, Rasmus Lerdorf wrote:
> Looks like this code in session.c is the culprit:
>
> int php_get_session_var(char *name, size_t namelen, zval ***state_var PLS_DC PSLS_DC
>ELS_DC)
> {
> HashTable *ht = &EG(symbol_table);
>
> if (!PG(register_globals))
>
Hey, is there some reason that using something like this isn't working?
[ses1.php]
[ses2.php]
ie. ses1.php starts a session and registers $test to be a session var and
then I define it in in the $HTTP_SESSION_VARS array. ses2.php simply
prints the value. With register_globals turned off thi
21 matches
Mail list logo
