On Aug 30, 2014 3:26 PM, "Matteo Beccati" <p...@beccati.com> wrote: > > On 30/08/2014 14:03, Chris Wright wrote: > > On 30 August 2014 12:53, Matteo Beccati <p...@beccati.com> wrote: > >> Even though size_t allows "huge" strings, would it be so bad to throw an > >> error when one tries to create a string longer than 2^32 bytes, > >> regardless of memory_limit? > > > > This would be an unnecessary and somewhat arbitrary limitation. Yes, > > loading >2GB of *anything* into memory in PHP *probably* makes no > > sense (probably 99% of real-world installations have memory_limit set > > much lower than this anyway), but just because we cannot think of a > > valid use case does not mean there isn't one. > > > > If the string index deref issue cannot be solved, it can simply be > > documented as only working for offsets up to 2^31, but I personally am > > not in favour of imposing limitations on the size of a string for a > > non-technical reason. > > Well, the only use case I can think of for strings >2GB involves > modifying it in place. Crazy, but valid nonetheless. Too bad string > offsets can't be used for the part exceeding the 2GB limit ;) > > Non-working string offsets to me sounds like a technical reason and not something arbitrary.
And the tech reason is? I do not know it yet but if it is only about using another type in the implementation it will not have any impact. But if it has an impact, let forget it, users should rely on stream then. Cheers,
