Re: 64 bit string offsets
| From: | Andrea Faulds | Date: | Fri, 29 Aug 2014 15:54:59 +0000 |
| Subject: | Re: 64 bit string offsets | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-76955@lists.php.net to get a copy of this message | ||
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.
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?
--
Andrea Faulds
http://ajf.me/