| Re: Completely stumped (still) [message #185070 is a reply to message #185068] |
Tue, 25 February 2014 19:34   |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma:
|
Senior Member |
|
|
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. $*_VARS were first.
> If that is so, register_globals is even far worse a feature than I
> thought.
ACK.
PointedEars
--
When all you know is jQuery, every problem looks $(olvable).
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]