On Fri, August 29, 2014 17:54, Andrea Faulds wrote: > > On 29 Aug 2014, at 16:49, Anatol Belski <anatol....@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
