Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76955
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.216 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <2afc5a878ff4c780c74f4604f77525c1.squirrel@webmail.klapt.com>
Date: Fri, 29 Aug 2014 16:54:59 +0100
Cc: 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>
Content-Transfer-Encoding: quoted-printable
Message-ID: <38C2ECB6-F38E-47C2-8C34-640FF0271FF7@ajf.me>
References: <2afc5a878ff4c780c74f4604f77525c1.squirrel@webmail.klapt.com>
To: Anatol Belski <anatol.php@belski.net>
Subject: Re: [PHP-DEV] 64 bit string offsets
From: ajf@ajf.me (Andrea Faulds)


On 29 Aug 2014, at 16:49, Anatol Belski <anatol.php@belski.net> wrote:

> Hi,
>=20
> while refining the big string support, it turned out that we've an =
issue.
> The syntax like $s[42] =3D '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.
>=20
> Also discussed with Laruence on IRC and he actually expressed the =
concern
> that we pay overhead on that. =46rom my side I was investigating on =
that and
> could suggest several solutions for that:
>=20
> - 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.
>=20
> 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=92t need to actually support >2GB string indexing realistically. =
As I understand it, we=92re using size_t because it=92s the proper type =
for string lengths, not because we need >2GB strings.

I=92d just leave things as they are=85 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?

--
Andrea Faulds
http://ajf.me/