I really don't see why would want to deprecate session_register(). Regardless of whether register_globals is on or off, code like this works fine:
Set a session var: session_register('a'); $a=1; Get a session var: session_start(); $a = $_SESSION['a']; This makes perfect sense to me and I see no reason to change that way of writing session code. -Rasmus On Wed, 2 Oct 2002, Ilia A. wrote: > On October 2, 2002 03:46 pm, Sascha Schumann wrote: > > > Its very simply really, as you well know, since PHP 4.2.0 > > > register_globals are off by default. Because they are off, > > > session_register does not retrieve a value from the variable and only > > > creates a null variable inside the session. So, unless the user is aware > > > of this issue and knows that to fix the problem they need to enable > > > register globals, which somewhat of a security risk, the application they > > > are trying to use won't work. Session is a fairly popular extension, it > > > is used by many PHP applications, so this is rather serious problem. > > > > You fail to see that an application is either designed to > > work with enabled register_globals, or it is not. There is > > little in between. If an application's session part fails > > because of register_globals, the rest of the application > > which handles input data will also fail. > > > > No magic code in the session extension will cure the support > > hassle created by the register_globals change. > > > > The main goal is to have a stable session extension with > > little to no behavioral changes from 4.2 to 4.3. Please keep > > that in mind. > > In this case, would it not be prudent to either depreciate the > session_register() function or add an E_NOTICE message in the event it is > used on a system with session_register() disabled? > That way we can atleast provide the users some idea as to why their code is > not working and perphaps make the 1st step towards eliminating > session_register() completely at some point in the future. > > > > My patch does not force the association between track and global > > > variables all the time, it is conditional on register_globals being > > > enabled. This does not prevent the user from having $test0 & > > > $_SESSION['test0'] as 2 seperate varaibles containing unrelated data. > > > > That's incorrect. Consider this code with your patch applied > > and register_globals=0: > > > > $c = "bla"; > > session_register("c"); > > // $_SESSION["c"] is now a ref to $c > > $_SESSION["c"] = "other stuff"; > > // voila, you now have changed the global variable $c > > That is quite correct. Of course it can be avoided by some additional hacking > to the code. However, based on your defenition of the goals for the session > extension, I believe it would be quite useless. > > Ilia > > -- > 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