Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77633
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c9ZKzFVozJpu3m54QM4=J22qgoLJ82NKr87v9jN=F3vpA@mail.gmail.com>
References: <CA+9eiLupqdnRWh3C=Q7Wa31NcDN_DUOa+uEXyAX78jcTn0OGcg@mail.gmail.com>
	<CAPwsocGF967ugDsACe0FALGJXY7NsgOT1TFAQE2sd2qxsskFaw@mail.gmail.com>
	<CA+9eiLuqfxBp-zQcc8aMFLAY53jHMsMu_PNSN6epdy62a+93KA@mail.gmail.com>
	<CAF+90c9ZKzFVozJpu3m54QM4=J22qgoLJ82NKr87v9jN=F3vpA@mail.gmail.com>
Date: Thu, 25 Sep 2014 22:45:18 +0200
Message-ID: <CAF+90c-30p5X2g1D-0fda-1pvGzta+QM5ETSra=1GdS9b=Y_7A@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: Leigh <leight@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01228626d991120503e9e0a6
Subject: Re: [PHP-DEV] [VOTE] Fix list() behavior inconsistency
From: nikita.ppv@gmail.com (Nikita Popov)

--089e01228626d991120503e9e0a6
Content-Type: text/plain; charset=UTF-8

On Thu, Sep 25, 2014 at 10:32 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Thu, Sep 25, 2014 at 1:15 PM, Dmitry Stogov <dmitry@zend.com> wrote:
>
>> disabling string handling would allow make operation simpler and would
>> improve regular access to array elements.
>> We won't need to check for (opline->extended_value & ZEND_FETCH_ADD_LOCK)
>> in FETCH_DIM_R handler.
>> However, it's going to be very small improvement, and I don't care a lot.
>> :)
>>
>> enabling string handling would require complication of
>> ZEND_FETCH_DIM_TMP_VAR handler (for strings support).
>> It's going to make list() handling a bit slower, but not significantly.
>>
>> my choice +1 for disabling.
>>
>
> Could you please clarify why removing string support would make the
> operation simpler? I voted for always supporting strings because I thought
> that is the option that simplifies things - in particular it would allow
> use to drop the FETCH_DIM_TMP_VAR opcode and always go through FETCH_DIM_R
> instead. Sample patch here:
> https://github.com/nikic/php-src/compare/stringOffsetsInList Or did I
> miss something and we can't do that?
>
> Nikita
>

I'd like to add that the FETCH_DIM_TMP_VAR opcode also provides incorrect
results if objects are used. list() generally accepts objects implementing
ArrayAccess, but if the object happens to be a TMP_VAR and
FETCH_DIM_TMP_VAR is used instead of FETCH_DIM_R, you'll just get a NULL
result:

<?php

class Arr implements ArrayAccess {
    private $arr;
    public function offsetGet($k) { return $this->arr[$k]; }
    public function offsetSet($k, $v) { $this->arr[$k] = $v; }
    public function offsetExists($k) { return isset($this->arr[$k]); }
    public function offsetUnset($k) { unset($this->arr[$k]); }
}

$arr = new Arr;
$arr[0] = 'foo';
$arr[1] = 'bar';

list($a, $b) = $arr;
var_dump($a, $b); // foo, bar

// (object) forces TMP_VAR
list($a, $b) = (object) $arr;
var_dump($a, $b); // NULL, NULL

So to handle that case we'd already have to extend the FETCH_DIM_TMP_VAR
handler to support objects in addition to arrays. At which point I don't
really see the point of making this a special case and would always use
FETCH_DIM_R instead (which already has all the necessary code to support
arrays, objects and strings).

Nikita

--089e01228626d991120503e9e0a6--