Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:74402 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 59736 invoked from network); 21 May 2014 06:22:51 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 May 2014 06:22:51 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; 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:46865] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 5B/15-24198-9364C735 for ; Wed, 21 May 2014 02:22:50 -0400 Received: (qmail 22289 invoked by uid 89); 21 May 2014 06:22:47 -0000 Received: by simscan 1.3.1 ppid: 22280, pid: 22284, t: 0.0814s 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; 21 May 2014 06:22:46 -0000 Message-ID: <537C4711.4010105@lsces.co.uk> Date: Wed, 21 May 2014 07:26:25 +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: In-Reply-To: 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 21/05/14 06:46, Yasuo Ohgaki wrote: >> As I have already said: 64bit (or rather 63bit) integer keys are already >> >supported on LP64 and ILP64 platforms. This proposal supports them on LLP64 >> >as well. The issue you're hitting has nothing to do with 64bit integers - >> >you are using a key that is*way* larger than that, i.e. a double key. >> >Double keys are handled by converting them to integers frist. This >> >conversion is a wraparound conversion, not a clamp conversion, so you end >> >up with some meaningless negative number. > > It was wrong example. However, if array int key size is 32bit, 64bit value > would never fit. > > I agree Rasmus's argument about string offset. If anyone would > like to deal with extremely large data, they should use stream or like. > It just wouldn't work well without it now. > > Regardless of this RFC acceptance or not, it's nice if all of these > limitations > are documented in the manual under single section. Perhaps, new > appendix? Of cause what adds to the fun here is the mixing of 'array' keys and 'string' keys in some of the recent 'improvements' to the language. If the array keys allow for 64bit integer values because 'integer' is a 64 bit value, then the mixing of string location as an additional dimension of the array should ideally match that? Personally I don't think the two have any place in the same context, but this has been added and now the additional fallout needs documenting? That a string integer index is different to an array integer index is the potential problem. Personally I would prefer that the use of the string index in this way was deprecated, and the nature of the string object was maintained within that object. Which would allow additional performance improvements if a string object limited to 16bit was also allowed? The string object would also then allow for UTF-8 support because the problem of string offsets are eliminated from the array indexing calculations? Will discussions in isolation are all very well, many of these elements are all interrelated ... -- 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