Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:74390 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 25082 invoked from network); 20 May 2014 21:55:04 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 May 2014 21:55:04 -0000 Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.214 mail4-2.serversure.net Linux 2.6 Received: from [217.147.176.214] ([217.147.176.214:46919] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A7/00-24198-53FCB735 for ; Tue, 20 May 2014 17:55:02 -0400 Received: (qmail 29785 invoked by uid 89); 20 May 2014 21:54:57 -0000 Received: by simscan 1.3.1 ppid: 29767, pid: 29782, t: 0.6951s scanners: attach: 1.3.1 clamav: 0.96/m:52 Received: from unknown (HELO linux-dev4.lsces.org.uk) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 20 May 2014 21:54:57 -0000 Message-ID: <537BD006.80405@lsces.co.uk> Date: Tue, 20 May 2014 22:58:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: internals@lists.php.net References: <537BC669.2030704@sugarcrm.com> In-Reply-To: <537BC669.2030704@sugarcrm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: 64bit and phpng, votes and plans From: lester@lsces.co.uk (Lester Caine) On 20/05/14 22:17, Stas Malyshev wrote: >> 64bit int if int is 64bit. I prefer consistency, so array int key is better >> >to support >> >64bit int key. IMHO. > Given that 99.9999% of PHP users will never need it, but 100% of PHP > users will pay in performance for each size increase, we need to be > careful here. "Consistency" is not more magic word than "security". Consistency is the main problem here. Most database engines use 64bit unique identifiers for SEQUENCE values. Upgrading systems that have been using 32bit integer values for this to support 64bit ones is the problem I've been living with. 32bit client apps get a string value where previously it was a simple integer. >> >Similar argument applies to string also. It would be WTF, when users try to >> >access string offset over 32bit values. Data dealt with PHP is getting >> >larger >> >and larger. It would be an issue sooner or later. > Not likely, unless somehow PHP becomes language of choice for processing > big data. Which I don't see exactly happening. But if it ever happens, > we can deal with it then. It is here today and has been for many years now. While the number of records may not be large, using large offsets can result in passing the 32bit boundary and what was an integer flips ... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk