Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:76968 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 30389 invoked from network); 30 Aug 2014 13:26:33 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 30 Aug 2014 13:26:33 -0000 Authentication-Results: pb1.pair.com header.from=php@beccati.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=php@beccati.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain beccati.com designates 176.9.114.167 as permitted sender) X-PHP-List-Original-Sender: php@beccati.com X-Host-Fingerprint: 176.9.114.167 spritz.beccati.com Received: from [176.9.114.167] ([176.9.114.167:54946] helo=mail.beccati.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7F/30-28092-701D1045 for ; Sat, 30 Aug 2014 09:26:33 -0400 Received: (qmail 19926 invoked from network); 30 Aug 2014 13:26:27 -0000 Received: from home.beccati.com (HELO ?192.168.1.202?) (88.149.176.119) by mail.beccati.com with SMTP; 30 Aug 2014 13:26:27 -0000 Message-ID: <5401D0FA.1080505@beccati.com> Date: Sat, 30 Aug 2014 15:26:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Chris Wright CC: Anatol Belski , Xinchen Hui , PHP Internals , Nikita Popov , Pierre Joye , Dmitry Stogov References: <2afc5a878ff4c780c74f4604f77525c1.squirrel@webmail.klapt.com> <8642f96d780f339c448bd330c6e1c097.squirrel@webmail.klapt.com> <5401BB3D.4060000@beccati.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: 64 bit string offsets From: php@beccati.com (Matteo Beccati) On 30/08/2014 14:03, Chris Wright wrote: > On 30 August 2014 12:53, Matteo Beccati 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. Cheer -- Matteo Beccati Development & Consulting - http://www.beccati.com/