Given:
$a[2] = '1';
$k = (double)2;
echo isset($a[$k]);
unset($a[$k]);
echo isset($a[$k]);
echo " -> expect 1\n";
Results:
11 -> expect 1
Although a double value isn't a valid array index, it doesn't seem
to be consistent. I'm thinking that the code should yeild one of
two results:
- Issue warning as with using objects or arrays as keys
- unset uses the str.val to retrieve the proper index.
Any thoughts on the proper behaviour?
Curt
First, let me assure you that this is not one of those shady pyramid schemes
you've been hearing about. No, sir. Our model is the trapezoid!
Although a double value isn't a valid array index, it doesn't seem
to be consistent. I'm thinking that the code should yeild one of
two results:
- Issue warning as with using objects or arrays as keys
- unset uses the str.val to retrieve the proper index.
Any thoughts on the proper behaviour?
There was a typo in Zend/zend_execute.c.
doubles used as indexes were being converted from the lval property of the
zval rather than the dval property.
This is similar to a bug that got patched about a month ago: $a[3.0] = 1;
acts like $a[0] = 1; just in a different spot.
Fixed now.
-Sara
- Thus wrote Sara Golemon:
Although a double value isn't a valid array index, it doesn't seem
to be consistent. I'm thinking that the code should yeild one of
two results:
- Issue warning as with using objects or arrays as keys
- unset uses the str.val to retrieve the proper index.
Any thoughts on the proper behaviour?
There was a typo in Zend/zend_execute.c.
doubles used as indexes were being converted from the lval property of the
zval rather than the dval property.
This is similar to a bug that got patched about a month ago: $a[3.0] = 1;
acts like $a[0] = 1; just in a different spot.Fixed now.
so I'm taking that as double's are allowed, so the documentation
need's to reflect that, since it currently says integers or strings
are only allowed.
correct?
And if so is this a php5 thing only or php4 also?
Thanks for fixing that!
Curt
First, let me assure you that this is not one of those shady pyramid schemes
you've been hearing about. No, sir. Our model is the trapezoid!
so I'm taking that as double's are allowed, so the documentation
need's to reflect that, since it currently says integers or strings
are only allowed.
Just make sure to mention that they are converted to integers first :)
Derick
so I'm taking that as double's are allowed, so the documentation
need's to reflect that, since it currently says integers or strings
are only allowed.
Sort of.....Strings and Integers ARE the only truly valid indices for
arrays. Other types are loosely allowed using some basic translation
criteria.
Doubles get converted to longs in a floor() style behavior:
i.e.: $a[1.1234] => $a[1], $a[980.829] => $a[980]
Booleans are converted to either 0 or 1:
i.e.: $a[false] => $a[0], $a[true] => $a[1]
Resources are translated to their resource ID number:
This is a little less obvious in its meaning. For example, if I $fp =
fopen('foo.txt', 'r') it'll return a resource, if you var_dump($fp) that
resource you might see something like: Resource #4 (stream). That "4" is
the unique identifier of the resource that the variable points to. What
this means for array indices is that: $a[$fp] => $a[4]
I don't particularly care for the behavior of resources, but eh whatcha
gonna do, it's probably there for BC reasons which go back to PHP3.
Apart from the above, only string and integer types are allowed which are
used untranslated:
$a[7] => $a[7]
$a['foo'] => $a['foo']
And if so is this a php5 thing only or php4 also?
This particular translation bug existed in ZE1 (PHP4) as well. I MFH'd the
fix already.
-Sara
Yep, and thanks Sara for fixing it.
At 11:34 AM 6/18/2004 -0700, Sara Golemon wrote:
Although a double value isn't a valid array index, it doesn't seem
to be consistent. I'm thinking that the code should yeild one of
two results:
- Issue warning as with using objects or arrays as keys
- unset uses the str.val to retrieve the proper index.
Any thoughts on the proper behaviour?
There was a typo in Zend/zend_execute.c.
doubles used as indexes were being converted from the lval property of the
zval rather than the dval property.
This is similar to a bug that got patched about a month ago: $a[3.0] = 1;
acts like $a[0] = 1; just in a different spot.Fixed now.
-Sara