| Re: Completely stumped (still) [message #185088 is a reply to message #185086] |
Tue, 25 February 2014 23:03   |
Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma:
|
Senior Member |
|
|
Thomas 'PointedEars' Lahn wrote:
> Christoph Michael Becker wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> Christoph Michael Becker wrote:
>>>> Jerry Stuckle wrote:
>>>> > On 2/24/2014 6:53 PM, Richard Yates wrote:
>>>> >> I inserted var_dump successively at each stage in the script to see
>>>> >> where it changes from the (correct) array to a (incorrect) string. I
>>>> >> narrowed it down to ONE statement, but cannot see how that could
>>>> >> possibly change the variable. Here's the section with var_dump, then
>>>> >> the one statement, and then the var_dump repeated exactly.
>>>> >>
>>>> >> var_dump($_SESSION['to']);
>>>> >> $to=$_SESSION['to'][$ct]['email'];
>>>> >> var_dump($_SESSION['to']);
>>>> >>
>>>> >> The output of the two var_dumps is:
>>>> >>
>>>> >> The first:
>>>> >> array(1) { [0]=> array(3)
>>>> >> { ["fname"]=> string(4) "Dick"
>>>> >> ["lname"]=> string(5) "Yates"
>>>> >> ["email"]=> string(23) "dyates(at)salemharvest(dot)org" }
>>>> >> }
>>>> >>
>>>> >> The second:
>>>> >> string(23) "dyates(at)salemharvest(dot)org"
>>>> >>
>>>> >> If I comment out the second line (that sets $to), the second var_dump
>>>> >> comes out correct. Am I losing my mind?
>>>> >
>>>> > The failing server has register_globals enabled.
>>>>
>>>> I'm still confused that it seems that register_globals makes the
>>>> respective global variables *references* to the session variables.
>>>
>>> Or both of them are references to the same array element. Whatever the
>>> implementation, it is the case that they yield the same value then, and
>>> it is – if I may say so – a *logical* consequence of how register_globals
>>> is supposed to work.
>>
>> However, GPC parameters are *copied* to the respective global variables.
>
> How did you get that idea?
As it doesn't seems to be explicitely documented, and I wanted some
confirmation before posting, I had made a quick test with following script:
var_dump($_GET['x']);
var_dump($x);
$x = 'bar';
var_dump($x);
var_dump($_GET['x']);
I requested the script with a query string of "x=foo". The output:
string(3) "foo" string(3) "foo" string(3) "bar" string(3) "foo"
(tested with PHP 5.2.13, FCGI, register_globals=On)
With $HTTP_GET_VARS instead of $_GET I get the same results
(register_long_arrays=On), by the way.
>> Why is it logical to make global variables references to session
>> variables (resp. let both reference the same variable/element)?
>
> The (error-prone, unsafe) shortcut that register_globals allowed would have
> been inconsistent otherwise.
IMHO only if the other parameters were also referenced.
>>> $*_VARS were first.
>>
>> According to the manual $HTTP_SESSION_VARS and $_SESSION are different
>> variables, anyway.[1]
>>
>> [1] <http://www.php.net/manual/en/reserved.variables.session.php>
>
> $_SESSION is a superglobal; $HTTP_SESSION_VARS is/was not (i.e., it needs to
> be declared a global if it is to be accessed from local context). But I am
> quite certain that when both were still supported, if you modified one, you
> modified the other (I have only PHP 5.5.9 to test with, where there is no
> $HTTP_SESSION_VARS anymore).
The manual says:
| $HTTP_SESSION_VARS contains the same initial information, but is not
| a superglobal. (Note that $HTTP_SESSION_VARS and $_SESSION are
| different variables and that PHP handles them as such)
--
Christoph M. Becker
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]