isset and unset behaviour

php.internals

Curt Zirzow

22 years ago
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: 1. Issue warning as with using objects or arrays as keys 2. 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!

Sara Golemon

22 years ago
> 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: > > 1. Issue warning as with using objects or arrays as keys > 2. 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

Curt Zirzow

22 years ago
* 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: > > > > 1. Issue warning as with using objects or arrays as keys > > 2. 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!

Derick Rethans

22 years ago
On Sat, 19 Jun 2004, Curt Zirzow wrote:
> 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

Sara Golemon

22 years ago
> 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

Andi Gutmans

22 years ago
Yep, and thanks Sara for fixing it. At 11:34 AM 6/18/2004 -0700, Sara Golemon wrote: