Hi,
2011/11/24 Richard Quadling <rquadl...@gmail.com>:
> On 23 November 2011 01:50, Daniel Convissor
> <dani...@analysisandsolutions.com> wrote:
>> Hi Folks:
>>
>> I just stumbled upon a regression in 5.4. In an array, a sub-sub-key of
>> an existing key is now returning a letter of the value indexed by the
>> main key. I'm raising it here so it doesn't get lost.
>>
>> https://bugs.php.net/bug.php?id=60362
>>
>> Thanks,
>>
>> --Dan
>
> I've just ran the code for the bug through all the V5
> releases/betas/alphas/RCs.
>
> V5.0.0 to V5.0.2
>
> BEHAVIOR CHANGED: sub-key 'non_existent' is not set.
> expected: sub-key 1 is set: string(1) "o"
> -------------------
> good: sub-sub-key 'sub_sub' is not set.
> good: sub-sub-key 0 is not set.
> -------------------
> BEHAVIOR CHANGED: sub-key 'non_existent' is empty.
> expected: sub-key 1 is NOT empty: string(1) "o"
> -------------------
> good: sub-sub-key 'sub_sub' is empty.
> good: sub-sub-key 0 is empty.
>
>
>
> V5.0.3 (don't have)
>
>
>
> V5.0.4 to V5.3.9RC2-dev (as at around 10am GMT on the 23rd Nov 2011).
> expected: sub-key 'non_existent' is set: string(1) "f"
> expected: sub-key 1 is set: string(1) "o"
> -------------------
> good: sub-sub-key 'sub_sub' is not set.
> good: sub-sub-key 0 is not set.
> -------------------
> expected: sub-key 'non_existent' is not empty: string(1) "f"
> expected: sub-key 1 is NOT empty: string(1) "o"
> -------------------
> good: sub-sub-key 'sub_sub' is empty.
> good: sub-sub-key 0 is empty.
>
>
>
> V5.4+ (betas and RCs)
> expected: sub-key 'non_existent' is set: string(1) "f"
> expected: sub-key 1 is set: string(1) "o"
> -------------------
> BEHAVIOR CHANGED: sub-key 'sub_sub' is set: string(1) "f"
> BEHAVIOR CHANGED: sub-sub-key 0 is set: string(1) "o"
> -------------------
> expected: sub-key 'non_existent' is not empty: string(1) "f"
> expected: sub-key 1 is NOT empty: string(1) "o"
> -------------------
> BEHAVIOR CHANGED: sub-sub-key 'sub_sub' is not empty: string(1) "f"
> BEHAVIOR CHANGED: sub-sub-key 0 is not empty: string(1) "o"
>
>
>
> So there was a previous bug fix in V5.0.2 (maybe 5.0.3).
>
> So, the whole type juggling point here is mute. It has been that way
> for a very long time. I just didn't realise it.
>
> And if that is a valid result
> (var_dump($arr['exists']['non_existent']) === 'f') - which it now is
> obviously is, then the change in V5.4 is certainly a bug fix.
>
> But, it is a significant enough issue that warrants a decent amount of
> documentation.
>
Nice effort for checking PHP 5.0.
I guess this difference comes from string offset access method change
introduced some where in 5.x.
Wasn't it supposed to access string offset like
<?php
$str = 'abc';
$c = $str{1};
var_dump($c);
Output from PHP 5.3
string(1) "b"
Accessing via [] is more consistent, so I prefer current method.
Howerver, following code executes with PHP 5.4
$ ./php -r '$s = "abc"; var_dump($s[0]["bar"]);
string(1) "a"
This is not right behavior. As far as I know, PHP only treat "string"
index as "integer" index if and only if "string was consisted only by
numbers".
I think current code is using convert_to_long() for sub array. It
should use string index to integer conversion code rather than
convert_to_long() to make consistent behavior.
With PHP 5.3, it rases fatal error
$ php -r '$s = "abc"; var_dump($s[0]["bar"]);'
PHP Fatal error: Cannot use string offset as an array in Command line
code on line 1
Raising notice error for accessing "string" by string offset seems to
be the feasible solution.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
