Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56590
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.170 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAKUjMCWpv98-+VfxkSEjCgRDXJ5KXZaGCEA=0Q=h0kvXEtuGHg@mail.gmail.com>
References: <20111123015008.GA12933@panix.com> <CAKUjMCWpv98-+VfxkSEjCgRDXJ5KXZaGCEA=0Q=h0kvXEtuGHg@mail.gmail.com>
Date: Fri, 25 Nov 2011 06:30:46 +0900
Message-ID: <CAGa2bXYARXzPXA5FS8q2ycmpULx9Y2BTVgdkcQireso1iUVN9Q@mail.gmail.com>
To: RQuadling@gmail.com
Cc: Daniel Convissor <danielc@analysisandsolutions.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi,

2011/11/24 Richard Quadling <rquadling@gmail.com>:
> On 23 November 2011 01:50, Daniel Convissor
> <danielc@analysisandsolutions.com> wrote:
>> Hi Folks:
>>
>> I just stumbled upon a regression in 5.4. =A0In an array, a sub-sub-key =
of
>> an existing key is now returning a letter of the value indexed by the
>> main key. =A0I'm raising it here so it doesn't get lost.
>>
>> https://bugs.php.net/bug.php?id=3D60362
>>
>> Thanks,
>>
>> --Dan
>
> I've just ran the code for the bug through all the V5 releases/betas/alph=
as/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']) =3D=3D=3D 'f') - which it now i=
s
> 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 =3D 'abc';
$c =3D $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 =3D "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 =3D "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
yohgaki@ohgaki.net