Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:74397 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 51311 invoked from network); 21 May 2014 05:21:35 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 May 2014 05:21:35 -0000 Authentication-Results: pb1.pair.com header.from=nikita.ppv@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=nikita.ppv@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.54 as permitted sender) X-PHP-List-Original-Sender: nikita.ppv@gmail.com X-Host-Fingerprint: 209.85.219.54 mail-oa0-f54.google.com Received: from [209.85.219.54] ([209.85.219.54:41532] helo=mail-oa0-f54.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 96/63-24198-ED73C735 for ; Wed, 21 May 2014 01:21:35 -0400 Received: by mail-oa0-f54.google.com with SMTP id j17so1714896oag.27 for ; Tue, 20 May 2014 22:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FzPjJbRdWgyTUekJDjulAXcWVM0qcsA8acOLn4Lbc1Q=; b=LNqW8AygRu/gb7s8w8K5KMOcKCD7DPbtLkUaAtGmWLRrnSk6TcjMk6B/LufSp8JTSt o9NSjfVzkcmXWW3zlIDAP19JIvxc9tWox5F855JrTe3To6a/3hTMOUM9XPhAS63ObJZf XPI1ll2jHA4tUcbTYYIrP2xK3ZjnJGg/VCPxnfkolLCM5PYUjv8M7TAmEUunF1Jg2OUZ 0Hgo7zqkadll0Dtuo4HtLXs9zsJ4X3zBJDZ88e0WBE10f/duI85ocM41hz4CDiEKRzjc rBOZjkqUZ4aIFnQqNvMpJhdAYIRma0j2EeJOUot+nXZ9M5slwqLl6eNmOKMV3o6RwguK KA5Q== MIME-Version: 1.0 X-Received: by 10.182.229.34 with SMTP id sn2mr48941504obc.6.1400649692261; Tue, 20 May 2014 22:21:32 -0700 (PDT) Received: by 10.182.165.69 with HTTP; Tue, 20 May 2014 22:21:32 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 May 2014 07:21:32 +0200 Message-ID: To: Yasuo Ohgaki Cc: Arvids Godjuks , PHP internals Content-Type: multipart/alternative; boundary=001a113497505cb0cc04f9e22ba9 Subject: Re: [PHP-DEV] Re: 64bit and phpng, votes and plans From: nikita.ppv@gmail.com (Nikita Popov) --001a113497505cb0cc04f9e22ba9 Content-Type: text/plain; charset=UTF-8 On Tue, May 20, 2014 at 11:12 PM, Yasuo Ohgaki wrote: > > On Wed, May 21, 2014 at 5:45 AM, Yasuo Ohgaki wrote: > >> This is the reason why DB data values and Web inputs should not be >> converted to native PHP data type blindly :) >> It could work, but it cannot work with 64bit int. >> > > It may be changed not to use int key (use string key) when int key > overflows, > then it would work. > > However, many users are trying to use strict type. Users may experience > data validation errors for large int with 32bit int key. It would be > better to allow > 64bit int if int is 64bit. I prefer consistency, so array int key is > better to support > 64bit int key. IMHO. > > 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. > 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. If you want to change the handling of double keys, that is - as far as I can see - an entirely different proposal, that's only tangentially related to 64bit support. Nikita --001a113497505cb0cc04f9e22ba9--