Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76957
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
Message-ID: <34613a1e18d788b25345d0227cdc1d2c.squirrel@webmail.klapt.com>
In-Reply-To: <38C2ECB6-F38E-47C2-8C34-640FF0271FF7@ajf.me>
References: <2afc5a878ff4c780c74f4604f77525c1.squirrel@webmail.klapt.com>
    <38C2ECB6-F38E-47C2-8C34-640FF0271FF7@ajf.me>
Date: Fri, 29 Aug 2014 18:39:54 +0200
To: "Andrea Faulds" <ajf@ajf.me>
Cc: "Anatol Belski" <anatol.php@belski.net>,
 internals@lists.php.net,
 "Nikita Popov" <nikita.ppv@gmail.com>,
 "Pierre Joye" <pierre.php@gmail.com>,
 "Dmitry Stogov" <dmitry@zend.com>,
 "Laruence" <laruence@php.net>
User-Agent: SquirrelMail/1.5.2 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] 64 bit string offsets
From: anatol.php@belski.net ("Anatol Belski")

On Fri, August 29, 2014 17:54, Andrea Faulds wrote:
>

> On 29 Aug 2014, at 16:49, Anatol Belski <anatol.php@belski.net> wrote:
>
>
>> Hi,
>>
>>
>> while refining the big string support, it turned out that we've an
> issue.
>> The syntax like $s[42] = 'x'; is currently inconsistend, because we
>> have uint32 for string offsets. This actually means, the behaviour is
> currently
>> only available in the old style and can handle not more than 2gb big
>> strings.
>>
>> Also discussed with Laruence on IRC and he actually expressed the
>>
> concern
>> that we pay overhead on that. From my side I was investigating on that
> and
>> could suggest several solutions for that:
>>
>> - stay with the old behavior (indexes would be able to handle only 2gb
>> strings, this is the status quo) - implement a function like in JS
>> String.charAt() as alternative
>> - turn to some temp_variable solution we currently have in PHP5.
>>
> Laruence
>
>> told be that dropping temp_variable was one of the improvementes.
>> Actually, the string index functionality is utilized in two opcodes, so
>>  maybe that were just a local case.
>>
>> Anyway not talking about touching zval, as that would grow by 8 bytes
>>
> with
>> a size_t str_offset. Just maybe there were another solution I oversee?
>
> We don’t need to actually support >2GB string indexing realistically. As
> I
> understand it, we’re using size_t because it’s the proper type for string
> lengths, not because we need >2GB strings.
The goal of the 64 bit RFC was to make everything work consistent across
64 bit platforms. That involved size_t and dynamic integer, for big
strings and integers. Now that we've merged it some parts might differ
from the original RFC. Whereby security and correct types are as well in
the background.

> I’d just leave things as they are… though I suppose there might be some
> benefit to switching to size_t for string offsets. Does that avoid a cast
> in the generated assembly?
My point is just that it should be consistent as we have it, in less or or
prefferably more plausible way. Though i didn't quite understand the
question about the compiled assembly - you mean whether it'll be binary
compatible with the previous bins? then no.

Regards

Anatol