Path: csiph.com!usenet.pasdenom.info!news.franciliens.net!news.muarf.org!nntpfeed.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="UTF-8" Message-ID: <7014311.eXnhZeaElC@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Tue, 25 Feb 2014 20:34:53 +0100 User-Agent: KNode/4.11.5 Content-Transfer-Encoding: 8Bit X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&. <530ceebc$0$9508$9b4e6d93@newsspool1.arcor-online.net> MIME-Version: 1.0 Lines: 48 NNTP-Posting-Date: 25 Feb 2014 20:34:56 CET NNTP-Posting-Host: b5f320e0.newsspool1.arcor-online.net X-Trace: DXC=6C[jokXL661gP]QSEBQ^d4ic==]BZ:af>4Fo<]lROoR1nkgeX?EC@@01CEWAg0_HN5DZm8W4\YJN8ZdD_1a;V8PK2CfK7mHH; X-Complaints-To: usenet-abuse@arcor.de Xref: csiph.com comp.lang.php:12968 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. $*_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).