Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76969
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5401D0FA.1080505@beccati.com>
References: <2afc5a878ff4c780c74f4604f77525c1.squirrel@webmail.klapt.com>
	<CABBJUpfeD3T1s5BpUvL-svtKXYxmHRbutzdagm+p8SOjuNnr_Q@mail.gmail.com>
	<8642f96d780f339c448bd330c6e1c097.squirrel@webmail.klapt.com>
	<5401BB3D.4060000@beccati.com>
	<CAGAGxbbtXyHPn85uYyO2v7QR3tbsyRyHZhhW06YXTNok_jsinA@mail.gmail.com>
	<5401D0FA.1080505@beccati.com>
Date: Sat, 30 Aug 2014 16:20:51 +0200
Message-ID: <CAEZPtU79vRZPikYdkoAB1+ug9PPAoTvcA8m3d1GLzcOxCB16WA@mail.gmail.com>
To: Matteo Beccati <php@beccati.com>
Cc: Dmitry Stogov <dmitry@zend.com>, PHP internals <internals@lists.php.net>, 
	Anatol Belski <anatol.php@belski.net>, Nikita Popov <nikita.ppv@gmail.com>, 
	Chris Wright <cw@daverandom.com>, Xinchen Hui <laruence@php.net>
Content-Type: multipart/alternative; boundary=001a11c303081d7cb90501d97a35
Subject: Re: [PHP-DEV] Re: 64 bit string offsets
From: pierre.php@gmail.com (Pierre Joye)

--001a11c303081d7cb90501d97a35
Content-Type: text/plain; charset=UTF-8

On Aug 30, 2014 3:26 PM, "Matteo Beccati" <php@beccati.com> wrote:
>
> On 30/08/2014 14:03, Chris Wright wrote:
> > On 30 August 2014 12:53, Matteo Beccati <php@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,

--001a11c303081d7cb90501d97a35--