Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76954
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: <2afc5a878ff4c780c74f4604f77525c1.squirrel@webmail.klapt.com>
Date: Fri, 29 Aug 2014 17:49:48 +0200
To: internals@lists.php.net
Cc: "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: 64 bit string offsets
From: anatol.php@belski.net ("Anatol Belski")

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?

Regards

Anatol