FWIW, I didn't manage to understand what the problem was with the codebase 
before the patch.  Sascha - can you explain it?

I tend to agree with Rasmus about this change being a not-so-good idea, but 
maybe we're just not aware of the problems that existed before the patch.

Zeev

At 19:09 09/10/2002, Rasmus Lerdorf wrote:
>Sascha, could we revisit these session changes?  I stuck current head on a
>server that runs all sorts of PHP code written by a bunch of different
>people.  These warnings were everywhere:
>
>   Warning: Your script possibly relies on a session side-effect which
>   existed until PHP 4.2.3. Please be advised that the session extension
>   does not consider global variables as a source of data, unless
>   register_globals is enabled. You can disable this functionality and
>   this warning by setting session.bug_compat_42 or session.bug_compat_warn.
>   in Unknown on line 0
>
>I'd like to do a collective rethink of this.  The simple description of
>the session_register() function in the manual is:
>
>  session_register() accepts a variable number of arguments, any of which
>  can be either a string holding the name of a variable or an array
>  consisting of variable names or other arrays. For each name,
>  session_register() registers the global variable with that name in the
>  current session.
>
>Now, there are further caveats about register_globals further on, but I
>would like to propose that we kill any and all such caveats and simply
>make the function behave exactly as described in the short description.
>Don't make its behaviour change based on register_globals or anything
>else.
>
>I don't see why calling session_register('a') should not register the
>global variable named $a in the session if that is what this function has
>always been documented to do, and in fact has always done regardless of
>the register_globals setting.  What is the drawback here?  I think the
>analogy to this is changing PHP such that you cannot do $a=1 to set a
>normal global variable when register_globals is off.  This obviously
>doesn't make any sense.  register_globals determines which things are
>injected into the global namespace, it does not determine whether we have
>a global namespace or how normal function interact with this global
>namespace.
>
>Basically my points are:
>
>  1. session_register('a') registering a global variable makes sense
>  2. changing this breaks BC
>
>-Rasmus
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to