what if you try :

<?
session_start();
session_register("foo");
session_register(4);
session_register("a");
session_register("counter");

print "<PRE>";
print "Current values:\n";
print '"foo"=' . $_SESSION["foo"] . "\n";
print '4=' . $_SESSION[4]."\n";
print '"a"=' . $_SESSION["a"]."\n";

$_SESSION["foo"] = "bar";
$_SESSION[4] = "four";
$_SESSION["a"] = "b";

if(!isset($_SESSION["counter"]))
     $_SESSION["counter"] = 1;
else
     $_SESSION["counter"]++;
print "Count = ".$_SESSION["counter"]."\n";
print "</PRE>";
?>


$_SESSION["foo"] and $_SESSION["counter"] should be working

$_SESSION[4] doesn't (I guess its because of the numerical key) and $_SESSION["a"] neither (but works if "a" is changed to "ab").

/Leblanc

Numerical indexes in $_SESSION are NOT supported.
(and never will be) 

User error -> bogus.

Ok, that seems reasonable. (Even though I cannot find anything in the manual that explicitly states that numerical indexes are unsupported) However, the setting of a numerical index seems to silently break something, since the other values in the example are affected as well. Is this really the intended behavior?

You're not supposed to do that. But it should indeed be documented.

I struggled with the $_SESSION problem for almost a week.  When I read this report, that is when reality hit me.  In the comment written by "sniper@php.net" saying that I'm not suppose to use the numberic value.  I'm using PHP 4.2.1 and AIX 4.3.3.  Here's the example that work which should not have work at all.  See the "//This one work!! (Numberic Value)".

Why do I have to spend almost a week struggling over it?  I read many documentation about $_SESSION vs. session_register() with the register_global turned off, but they say nothing about the numeric value that aren't allowed to be used?

Thanks,
 FletchSOD

--clip--
//-------Page 1---------
define(CUSTOMER_ID,0);
define(CUSTOMER_NAME,1);
define(STREET,4);
define(CITY,5);
define(STATE,6);
define(ZIP_CODE,7);

$salt = strtoupper(md5(uniqid(rand())));
session_id($salt);
session_start();

//$result is from odbc_exec
odbc_fetch_into($result,$_SESSION,1);

//Example #1
print_r($_SESSION);   //This one work!! (Numeric Value)

//Example #2
echo $_SESSION[0];  //This one work also! (Numberic Value)

header("Location: https://www.whatever.com/page2.php");
//-------Page 2---------
session_start();

print_r($_SESSION);  //This one does not work!
--clip--

Whoop!  One more thing!  $_SESSION[CUSTOMER_ID] does work on page 1 also!  Didn't include that as Example #3 on page 1.

As session variables are subject to be registered as global variables (if register_globals is on), and identifier names (including variable names) cannot begin with a numeric character, it's not too hard to see that session variables should not begin with a number. Basically session variables
should follow naming ruiles for identifiers IMHO.

This test case I posted is with register_global turned off.  Well, the documentation should stated that the number can not be used as the first character.  I wonder how can anyone tell the difference on $_SESSION from an array?  It look a lot like an array in some way.

I've been having a similar problem for over a week. Tried everything I could think of.  Script looked like this:

<?
GLOBAL $HTTP_SESSION_VARS;
session_start();
$AVAR += 1;
session_register('AVAR');
 
print "<p>variable={$HTTP_SESSION_VARS['AVAR']}</p>";
?>

Seemed everyone else could get it to work except for a friend and I. I'm using IE 6.0.28, he's using Netscape 4.04.
I was able to correct the problem by doing the following while running IE6.0.28:

a) Select Tools/Internet Options
b) Select Privacy Tab
c) Click on Advanced button
d) Check Override Automatic Cookie Handling
e) Check Always allow session cookies

After doing this - everything worked fine - even the test scripts above (except for the variable 4).

I then went back and unchecked the Override Automatic Cookie Handling - assuming that this would return me back to a state where AVAR would not increment.  Much to my chagrin, it continued to work.  This leads me to believe that there's a registry setting somewhere that controls this behavior.  Now, to find out what it is and how to check for it on a user's machine from within PHP.....

This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.

Added comment on the limitations for variable names in the documentation.

numeric keys may not be supported, but lets say you do:

$_SESSION[4]='something';
$_SESSION['four']='something';

you will lose both session keys in the next load.

in other words, any session key/value pair created in 
the script after the numeric key are lost, but the ones 
before are kept.