Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #12929 > unrolled thread

Completely stumped

Back to article view | Back to comp.lang.php

Contents

  Completely stumped Richard Yates <richard@yatesguitar.com> - 2014-02-24 14:51 -0800
    Re: Completely stumped (still) Richard Yates <richard@yatesguitar.com> - 2014-02-24 15:53 -0800
      Re: Completely stumped (still) Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 01:11 +0100
        Re: Completely stumped (still) Richard Yates <richard@yatesguitar.com> - 2014-02-24 16:24 -0800
          Re: Completely stumped (still) Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 01:49 +0100
            Re: Completely stumped (still) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-25 03:37 +0100
              Re: Completely stumped (still) Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-24 22:01 -0500
                Re: Completely stumped (still) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-25 19:38 +0100
                  Re: Completely stumped (still) Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-25 14:06 -0500
                    Re: Completely stumped (still) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-25 20:28 +0100
                      Re: Completely stumped (still) Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-25 16:04 -0500
      Re: Completely stumped (still) Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-24 20:59 -0500
        Re: Completely stumped (still) Richard Yates <richard@yatesguitar.com> - 2014-02-24 19:00 -0800
          Re: Completely stumped (still) Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-24 22:04 -0500
            Re: Completely stumped (still) Richard Yates <richard@yatesguitar.com> - 2014-02-24 21:09 -0800
              Re: Completely stumped (still) Richard Yates <richard@yatesguitar.com> - 2014-02-24 21:30 -0800
        Re: Completely stumped (still) Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 20:27 +0100
          Re: Completely stumped (still) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-25 20:34 +0100
            Re: Completely stumped (still) Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-25 22:46 +0100
              Re: Completely stumped (still) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-25 23:30 +0100
                Re: Completely stumped (still) Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-26 00:03 +0100
                  Re: Completely stumped (still) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-26 00:29 +0100
                    Re: Completely stumped (still) Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-26 19:50 +0100
                      Re: Completely stumped (still) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-02-26 22:20 +0100
                        Re: Completely stumped (still) Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-27 00:21 +0100
          Re: Completely stumped (still) Richard Yates <richard@yatesguitar.com> - 2014-02-25 12:39 -0800
          Re: Completely stumped (still) Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-25 16:06 -0500

Page 2 of 2 — ← Prev page 1 [2]

#12986 — Re: Completely stumped (still)

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@salemharvest.org" }
>>>>>>              }
>>>>>>
>>>>>> The second:
>>>>>>     string(23) "dyates@salemharvest.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

[toc] | [prev] | [next] | [standalone]

#12989 — Re: Completely stumped (still)

Christoph Michael Becker wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Christoph Michael Becker wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Christoph Michael Becker wrote:
>>>>> 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.

ACK.  Session variables must be different, though.
 
>>>  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.

Do you think it is a consistent implementation if you can read a session 
value using a global variable, but not modify it this way?
 
>>>>                    $*_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)

I *know* what the manual says.  That does not prove anything.

(Puzzling, but probably not relevant because of the newer PHP version:

$ php -r 'session_start(); var_dump($HTTP_SESSION_VARS["foo"]); 
$_SESSION["foo"] = "bar"; var_dump($HTTP_SESSION_VARS["foo"]); 
var_dump($_SESSION);'PHP Notice:  Undefined variable: HTTP_SESSION_VARS in 
Command line code on line 1
PHP Stack trace:
PHP   1. {main}() Command line code:0
NULL
PHP Notice:  Undefined variable: HTTP_SESSION_VARS in Command line code on 
line 1
PHP Stack trace:
PHP   1. {main}() Command line code:0
NULL
array(1) {
  'foo' =>
  string(3) "bar"
}

$ php -r 'session_start(); global $HTTP_SESSION_VARS; 
var_dump($HTTP_SESSION_VARS["foo"]); $_SESSION["foo"] = "bar"; 
var_dump($HTTP_SESSION_VARS["foo"]); var_dump($_SESSION);'
NULL
NULL
array(1) {
  'foo' =>
  string(3) "bar"
}

$ php -v
PHP 5.5.9-1 (cli) (built: Feb  8 2014 00:52:52) 
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
    with XCache v3.1.0, Copyright (c) 2005-2013, by mOo
    with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies
    with Xdebug v2.2.3, Copyright (c) 2002-2013, by Derick Rethans
    with XCache Optimizer v3.1.0, Copyright (c) 2005-2013, by mOo
    with XCache Cacher v3.1.0, Copyright (c) 2005-2013, by mOo
    with XCache Coverager v3.1.0, Copyright (c) 2005-2013, by mOo
)


PointedEars
-- 
    realism:    HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness:    XHTML 1.1 as application/xhtml+xml
                                                    -- Bjoern Hoehrmann

[toc] | [prev] | [next] | [standalone]

#13001 — Re: Completely stumped (still)

Thomas 'PointedEars' Lahn wrote:

> Christoph Michael Becker wrote:
> 
>> Thomas 'PointedEars' Lahn wrote:
>>> Christoph Michael Becker wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>
>>>>  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.
> 
> Do you think it is a consistent implementation if you can read a session 
> value using a global variable, but not modify it this way?

Well, I see your point.  While it usually makes no sense to modify
$_GET, $_POST or $_COOKIE, modifying $_SESSION does.  However, this
difference (reference assignment vs. copying) is still somewhat
confusing, IMHO.

>>>>>                    $*_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)
> 
> I *know* what the manual says.  That does not prove anything.

Testing on a single system might not prove much more, either.  Anyway, I
tested the following script on PHP 5.2.13 (FCGI, register_globals=On or
Off, register_long_arrays=On):

    <?php

    session_start();
    var_dump($HTTP_SESSION_VARS["foo"]);
    $_SESSION["foo"] = "bar";
    var_dump($HTTP_SESSION_VARS["foo"]);

The result really surprised me:

 string(3) "bar" string(3) "bar"

The output is the same, if I switch $HTTP_SESSION_VARS and $_SESSION.  A
similar test regarding $_GET and $HTTP_GET_VARS showed the documented
behavior, by the way.

It seems that is a documentation bug.  However, I suppose that's mostly
irrelevant now, because the bug tracker is concerned with PHP 5.4-5.6,
and says wrt. earlier versions: "upgrade first".  But since PHP 5.4
register_long_arrays has been removed, so I conclude that the
$HTTP_*_VARS have been removed also, in which case their documentation
is even more in error, because it states they are deprecated, but
doesn't mention that they have been removed.  Now I am completely stumped.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#13005 — Re: Completely stumped (still)

Christoph Michael Becker wrote:

> Thomas 'PointedEars' Lahn wrote: 
>> Christoph Michael Becker wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Christoph Michael Becker wrote:
>>>>> Thomas 'PointedEars' Lahn wrote:
>>>>>>                    $*_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)
>> 
>> I *know* what the manual says.  That does not prove anything.
> 
> Testing on a single system might not prove much more, either.  Anyway, I
> tested the following script on PHP 5.2.13 (FCGI, register_globals=On or
> Off, register_long_arrays=On):
> 
>     <?php
> 
>     session_start();
>     var_dump($HTTP_SESSION_VARS["foo"]);
>     $_SESSION["foo"] = "bar";
>     var_dump($HTTP_SESSION_VARS["foo"]);
> 
> The result really surprised me:
> 
>  string(3) "bar" string(3) "bar"
> 
> The output is the same, if I switch $HTTP_SESSION_VARS and $_SESSION.  A
> similar test regarding $_GET and $HTTP_GET_VARS showed the documented
> behavior, by the way.
> 
> It seems that is a documentation bug.

ACK.

> However, I suppose that's mostly rrelevant now, because the bug tracker is
> concerned with PHP 5.4-5.6, and says wrt. earlier versions: "upgrade
> first".  But since PHP 5.4 register_long_arrays has been removed, so I
> conclude that the $HTTP_*_VARS have been removed also,

They have been removed indeed, as you can see in my PHP 5.5 test results.

I found it curiouser, though, that you can use “global” outside a function.  
And not only that (which makes some sense as the file can be included), but 
that apparently you can actually *declare* a global variable in PHP this way 
(in my case, the previously non-existing $HTTP_SESSION_VARS).

> in which case their documentation is even more in error, because it states
> they are deprecated, but doesn't mention that they have been removed.
> Now I am completely stumped.

ACK.


PointedEars
-- 
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[toc] | [prev] | [next] | [standalone]

#13012 — Re: Completely stumped (still)

Thomas 'PointedEars' Lahn wrote:

> Christoph Michael Becker wrote:
> 
>> Thomas 'PointedEars' Lahn wrote: 
>>> Christoph Michael Becker wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>> Christoph Michael Becker wrote:
>>>>>> Thomas 'PointedEars' Lahn wrote:
>>>>>>>                    $*_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)
>>>
>>> I *know* what the manual says.  That does not prove anything.
>>
>> Testing on a single system might not prove much more, either.  Anyway, I
>> tested the following script on PHP 5.2.13 (FCGI, register_globals=On or
>> Off, register_long_arrays=On):
>>
>>     <?php
>>
>>     session_start();
>>     var_dump($HTTP_SESSION_VARS["foo"]);
>>     $_SESSION["foo"] = "bar";
>>     var_dump($HTTP_SESSION_VARS["foo"]);
>>
>> The result really surprised me:
>>
>>  string(3) "bar" string(3) "bar"
>>
>> The output is the same, if I switch $HTTP_SESSION_VARS and $_SESSION.  A
>> similar test regarding $_GET and $HTTP_GET_VARS showed the documented
>> behavior, by the way.
>>
>> It seems that is a documentation bug.
> 
> ACK.
> 
>> However, I suppose that's mostly rrelevant now, because the bug tracker is
>> concerned with PHP 5.4-5.6, and says wrt. earlier versions: "upgrade
>> first".  But since PHP 5.4 register_long_arrays has been removed, so I
>> conclude that the $HTTP_*_VARS have been removed also,
> 
> They have been removed indeed, as you can see in my PHP 5.5 test results.
> 
> I found it curiouser, though, that you can use “global” outside a function.  
> And not only that (which makes some sense as the file can be included), but 
> that apparently you can actually *declare* a global variable in PHP this way 
> (in my case, the previously non-existing $HTTP_SESSION_VARS).

Indeed, the behavior is somewhat strange.  However, it becomes more
understandable, considering what global actually does: it creates a
local variable as a reference to the respective global variable.  So the
following functions are equivalent (if I'm not mistaken):

  function foo() {
    global $a;
    echo $a;
  }

  function bar() {
    $a =& $GLOBALS['a'];
    echo $a;
  }

>> in which case their documentation is even more in error, because it states
>> they are deprecated, but doesn't mention that they have been removed.
>> Now I am completely stumped.
> 
> ACK.

Thanks for the confirmation.  I have filed a doc bug report now[1].

[1] <https://bugs.php.net/bug.php?id=66784>


-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#12971 — Re: Completely stumped (still)

On Tue, 25 Feb 2014 20:27:59 +0100, Christoph Michael Becker
<cmbecker69@arcor.de> 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@salemharvest.org" }
>>>              }
>>>
>>> The second:
>>>     string(23) "dyates@salemharvest.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.  If
>that is so, register_globals is even far worse a feature than I thought.

From what I have been able to glean from forums it can be  a
nightmare. I found this bit on StackOverflow:

$_SESSION[x] = 123;
$x = 'asd';
echo $_SESSION[x];
The output will be asd if register_globals is on.

I was doing the equivalent of $x=$_SESSION['x'] for the second line
which made it a double whammy. It seemed reasonable, tidy and easy to
keep track of to use the same name for the regular variable as the
_SESSION variable. I do that with _GET and _POST sometimes, too. At
least it turned out to be easy to turn register_globals off once Jerry
had pointed me there.

[toc] | [prev] | [next] | [standalone]

#12975 — Re: Completely stumped (still)

On 2/25/2014 2:27 PM, 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@salemharvest.org" }
>>>               }
>>>
>>> The second:
>>>      string(23) "dyates@salemharvest.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.  If
> that is so, register_globals is even far worse a feature than I thought.
>

That is how it works.  And while it seemed like a good idea in the 
beginning, as of PHP 4.2 the recommendation was not to use it any more.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.php

csiph-web