php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #21918 strange behaviour of mixed type in array-keys
Submitted: 2003-01-28 04:58 UTC Modified: 2003-08-13 13:44 UTC
Votes:3
Avg. Score:4.0 ± 0.8
Reproduced:3 of 3 (100.0%)
Same Version:1 (33.3%)
Same OS:2 (66.7%)
From: messju at lammfellpuschen dot de Assigned: zeev (profile)
Status: Closed Package: Scripting Engine problem
PHP Version: 4.3.3-RC3/5.0.0b2 OS: *
Private report: No CVE-ID: None
View Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
11 + 15 = ?
Subscribe to this entry?

 
 [2003-01-28 04:58 UTC] messju at lammfellpuschen dot de 
<?php

$a = array(-1=>1,
           '-1'=>2,
           0=>3,
           '0'=>4,
           1=>5,
           '1'=>6
           );

print_r($a);

?>

produces:
Array
(
    [-1] => 1
    [-1] => 2
    [0] => 4
    [1] => 6
)


foreach (array_keys($a) as $key) echo $key, ': ', gettype($key), "\n";
produces:
-1: integer
-1: string
0: integer
1: integer

so it seems strings containing negative integers do not get converted to
integers automagically but positive integers are.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-01-29 00:57 UTC] sniper@php.net 
<?php

$a = array(
 '-1' => '-1',
  '0' => '0',
  '1' => '1',
);

var_dump($a);

?>

Output:

array(3) {
  ["-1"]=>
  string(2) "-1"
  [0]=>
  string(1) "0"
  [1]=>
  string(1) "1"
}

(the '0' and '1' indexes are converted to integers..)
Not sure if this is actually expected behaviour. :)
 [2003-01-29 02:22 UTC] messju at lammfellpuschen dot de 
I relied on http://www.php.net/manual/en/language.types.array.php

it states:

"A key is either an integer or a string. If a key is the standard representation of an integer, it will be interpreted as such (i.e. "8" will be interpreted as 8, while "08" will be interpreted as "08")."

so the keys should be casted to int, or it is a documentation-bug, or "-1" is not a "standard representation of an integer".
 [2003-02-08 12:35 UTC] moriyoshi@php.net 
Related to bug #8325
 [2003-08-11 15:15 UTC] helly@php.net 
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.
 [2003-08-12 15:46 UTC] helly@php.net 
Broken again
 [2003-08-12 18:45 UTC] sniper@php.net 
Zeev could at least explain WHY he reverted the fix..
 [2003-08-13 02:55 UTC] zeev@php.net 
It's not 'broken' again, what I reverted had nothing to do with this bug.  Look at the diff before you start shouting!

I'm still not sure if we'll keep the auto conversion for negative numbers.  My preference is to fix the docs, since all sorts of other notations don't work, and we have no intention on making them work (e.g., $foo["+7"], $foo["3.5"], etc.
 [2003-08-13 04:18 UTC] sniper@php.net 
Zeev is right about this being the wrong bug reopened, this is (still) fixed in CVS.
 [2003-08-13 13:44 UTC] helly@php.net 
Well i didn't mean to shout or something like that :-)

I reopened the bug because the part of the fix removed was for documentation consistency. And i didn't want to open a new bug on this.

To be precise: "A key may be either an integer or a string. If a key is the standard representation of an integer, it will be interpreted as such (i.e. "8" will be interpreted as 8, while "08" will be interpreted as "08"). There are no different indexed and associative array types in PHP; there is only one array type, which can both contain integer and string indices." (1)

The above is the exact purpose of this bug and is fixed now.

The inconsistency lies in this: "If you do not specify a key for a given value, then the maximum of the integer indices is taken, and the new key will be that maximum value + 1. If you specify a key that already has a value assigned to it, that value will be overwritten." (2)

While the documentation says: "As of PHP 4.3.0, the index generation behaviour described above has changed. Now, if you append to an array in which the current maximum key is negative, then the next key created will be zero (0). Before, the new index would have been set to the largest existing key + 1, the same as positive indices are." (3)

Since (1) and (2) were broken in PHP 4.3 i didn't really care about the note (3). If we leave the things as they are now (1) throughtout (3) match. However i like the behavior without (3) more since it is consistent and more logically.
 [2011-10-20 07:18 UTC] sushant dot d84 at gmail dot com 
I have an array which I use for long Binary Tree. I am pasting the array here 
which shows the negative key. 

The code was very general 
$i=0;
while ($MyCondition) 
{
$i=$i*2+1;
temparray[$i]= $MyItem; 
$i=$i*2+2;
temparray[$i]= $MyItem; 
}



and the output has one negative key in it.. 


"    [-2147483648] =>    "
 [2011-10-20 07:21 UTC] sushant dot d84 at gmail dot com 
I have an array which I use for long Binary Tree. I am pasting the array here 
which shows the negative key. 

The code was very general 
$i=0;
while ($MyCondition) 
{
$i=$i*2+1;
temparray[$i]= $MyItem; 
$i=$i*2+2;
temparray[$i]= $MyItem; 
}



and the output has one negative key in it.. 


"    [-2147483648] =>    "

Thanks and Regards
Sushant Danekar 
http://Splendornet.com
http://vidility.com/blog
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Wed Oct 29 23:00:01 2025 UTC