Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:78056 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 76349 invoked from network); 14 Oct 2014 19:46:21 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Oct 2014 19:46:21 -0000 Authentication-Results: pb1.pair.com header.from=ajf@ajf.me; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=ajf@ajf.me; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain ajf.me designates 198.187.29.245 as permitted sender) X-PHP-List-Original-Sender: ajf@ajf.me X-Host-Fingerprint: 198.187.29.245 imap11-3.ox.privateemail.com Received: from [198.187.29.245] ([198.187.29.245:47168] helo=imap11-3.ox.privateemail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 3E/43-18603-D8D7D345 for ; Tue, 14 Oct 2014 15:46:21 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.privateemail.com (Postfix) with ESMTP id 0E5D58800D5; Tue, 14 Oct 2014 15:46:19 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at imap11.ox.privateemail.com Received: from mail.privateemail.com ([127.0.0.1]) by localhost (imap11.ox.privateemail.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MsyLDj78aHEr; Tue, 14 Oct 2014 15:46:18 -0400 (EDT) Received: from [10.0.110.86] (border-converged.hackerdeen.org [89.104.225.218]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.privateemail.com (Postfix) with ESMTPSA id 3523688000A; Tue, 14 Oct 2014 15:46:17 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) In-Reply-To: <543D7116.2050702@lsces.co.uk> Date: Tue, 14 Oct 2014 20:46:14 +0100 Cc: "internals@lists.php.net >> PHP internals" Content-Transfer-Encoding: quoted-printable Message-ID: <28664CF1-DF8E-4AE7-998F-D79B42ABB508@ajf.me> References: <8C47FA53-0964-49C0-963C-332A936348A5@ajf.me> <543CE41B.5020308@sugarcrm.com> <543D5C78.9040905@sugarcrm.com> <543D61F3.3000000@lsces.co.uk> <543D6B9E.4000205@lsces.co.uk> <30774AB4-3546-4A13-96C6-B511C9F6E12E@ajf.me> <543D7116.2050702@lsces.co.uk> To: Lester Caine X-Mailer: Apple Mail (2.1878.6) Subject: Re: [PHP-DEV] [RFC] Big Integer Support From: ajf@ajf.me (Andrea Faulds) On 14 Oct 2014, at 19:53, Lester Caine wrote: > The real life situation is that databases have used a 64bit integer as > the primary key for records in a table for a long time now. Loading > these records into arrays using the primary key as the array key is a > natural process but as you have identified currently once they go over = a > 32 bit value they switch from simple integer to strings. Upgrading PHP > to natively support 64bit integers on 64bit platforms but leaving them > as 32bit on 32bit platforms is creating an inconsistency which this = rfc > seems to be making more complex rather than less. This why I was = simply > looking for a 64bit integer type that works as a simple integer on = 32bit > platforms as well. GMP is overkill for this simple case and only = needed > when one actually needs integers bigger than 64bit, and normal > programming does not need that in PHP7, just a clean 64bit integer. > Currently we can do any necessary 64bit maths on the keys in the > database, but for cross database working a consistent solution inside > PHP would help. Well, you also get 64-bit support for free with GMP. Maybe it=92s = =93overkill=94, but it does solve your use case. If you really want to go and add 64-bit emulation to 32-bit builds, be = my guest. But nobody=92s gone and done that. -- Andrea Faulds http://ajf.me/