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