Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56552
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)
Message-ID: <4ECDAEE5.7020205@gmail.com>
Date: Thu, 24 Nov 2011 13:41:41 +1100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20111031 Thunderbird/7.0.1
MIME-Version: 1.0
To: Ferenc Kovacs <tyra3l@gmail.com>
CC: Stas Malyshev <smalyshev@sugarcrm.com>, 
 Daniel Convissor <danielc@analysisandsolutions.com>,
 Lester Caine <lester@lsces.co.uk>, 
 PHP internals <internals@lists.php.net>
References: <20111123015008.GA12933@panix.com> <CACQesk6UuGUgyJz3hsGVE0crJx3GCkjTTpLb4xNGTm1goLzO8Q@mail.gmail.com> <20111123023108.GA172@panix.com> <CACQesk5kj=4kzvTDiLL1oOLBXZrn4WdUcLXdbyMLTa=OdhGTcw@mail.gmail.com> <4ECCB549.904@lsces.co.uk> <4ECCBC56.3050602@sugarcrm.com> <20111123141408.GA11940@panix.com> <4ECD40E2.1000601@sugarcrm.com> <CAH-PCH6f30p6AfNT9z=wVPURo4ko08sMTwHiEQsdpauN-cYtwQ@mail.gmail.com> <4ECD48AD.1020207@sugarcrm.com> <4ECD91F4.5040303@gmail.com> <CAH-PCH7GCDOdnHve-mNdkPYbBN+WGLJN2BP8pdpXmVz=0FQ0mg@mail.gmail.com>
In-Reply-To: <CAH-PCH7GCDOdnHve-mNdkPYbBN+WGLJN2BP8pdpXmVz=0FQ0mg@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------060007050606040500040202"
Subject: Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have
 values
From: davidkmuir@gmail.com (David Muir)

--------------060007050606040500040202
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 24/11/11 12:44, Ferenc Kovacs wrote:
>
>
> On Thu, Nov 24, 2011 at 1:38 AM, David Muir <davidkmuir@gmail.com
> <mailto:davidkmuir@gmail.com>> wrote:
>
>     Just to clarify, the changes introduced in 5.4 will result in the
>     following:
>
>     <?php
>
>     $string = 'foo';
>     $array = array(
>        'foo' => array(
>            'bar' => 'baz',
>            //expected structure
>            //'bar' => array('baz' => array('values'))
>     ));
>
>     var_dump(
>        isset($string['foo']), //true
>        isset($string[0][0]), //false, true in 5.4
>        isset($array['foo']['bar'][0]), //true
>        isset($array['foo']['bar']['baz']), //true
>        isset($array['foo']['bar']['baz']['0']) //false, true as of 5.4
>        isset($string['foo']['bar']['baz']['0']) //false, true as of 5.4
>     );
>
>
> you are missing a comma from the end of the
> isset($array['foo']['bar']['baz']['0']) //false, true as of 5.4
> line

Yeah, I added that one at the last minute. That's what I get for a quick
copy/paste...

>
> isset($string['foo']['bar']['baz']['0']) //false, true as of 5.4
> gives me a fatal error on 5.3 ("PHP Fatal error:  Cannot use string
> offset as an array" as you can't "chain" string offsets before 5.4)
>

It gives me false in 5.3.6. Using it outside of isset() results in the
fatal error.

>  
>
>
>     What used to be a one-liner, now effectively needs a crapload of
>     boilerplate code.
>
>
> yeah, if you can't trust the data structures in your code, then you
> have to validate it.
> don't forget that this bug could also bite you with 5.3:

True, it does fail in 5.3 in some places, but it now fails in more
places with 5.4. Maybe what's triggering the hostile reaction to this
change is that people incorrectly assumed that they were validating it
in a valid manner. The docs for isset states that it works for array
keys, but there's no mention about the string offset gotcha, and it's a
much more convenient option that using array_key_exists + is_array for
each level.

Can we add the lines:

var_dump(isset($a['pie']['a'][0]));        // TRUE
var_dump(isset($a['pie']['a']['b']));        // TRUE

to the isset docs? At least then the current behaviour would be
documented. And maybe add Anthony Ferrera's tip that only the last
element needs an array check?


> Personally I think that the main issue is that we silently convert
> $foo['bar'] to $foo[0] for strings, which imo rarely the intended
> behavior and doesn't really makes much sense (except that the offset
> expects the index to be int, and this is how we type juggle between
> string and int), so I think it would be a good idea to raise a notice
> here, so the developer can fix his code, or add some input validation.

That would be a help.


Cheers,
David

--------------060007050606040500040202--