Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76956
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.215.46 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <2afc5a878ff4c780c74f4604f77525c1.squirrel@webmail.klapt.com>
References: <2afc5a878ff4c780c74f4604f77525c1.squirrel@webmail.klapt.com>
Date: Sat, 30 Aug 2014 00:34:25 +0800
Message-ID: <CABBJUpfeD3T1s5BpUvL-svtKXYxmHRbutzdagm+p8SOjuNnr_Q@mail.gmail.com>
To: Anatol Belski <anatol.php@belski.net>
Cc: PHP Internals <internals@lists.php.net>, Nikita Popov <nikita.ppv@gmail.com>, 
	Pierre Joye <pierre.php@gmail.com>, Dmitry Stogov <dmitry@zend.com>
Content-Type: text/plain; charset=UTF-8
Subject: Re: 64 bit string offsets
From: laruence@php.net (Xinchen Hui)

On Fri, Aug 29, 2014 at 11:49 PM, 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)

I think it's okey. maybe throw a warning if it's bigger than 32bits?

if a string is bigger than 2^32... I think there must be a bug.... :)

thanks

> - 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



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/