Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:48367 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 71229 invoked from network); 20 May 2010 21:22:41 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 May 2010 21:22:41 -0000 X-Host-Fingerprint: 209.131.62.146 nat-dip11.cfw-b-gci.corp.yahoo.com Received: from [209.131.62.146] ([209.131.62.146:11473] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CD/56-45208-028A5FB4 for ; Thu, 20 May 2010 17:22:40 -0400 Message-ID: To: internals@lists.php.net Date: Thu, 20 May 2010 14:22:36 -0700 User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 References: <7A.44.45208.19295FB4@pb1.pair.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 209.131.62.146 Subject: Re: [PHP-DEV] json_decode() and integers larger than LONG_MAX (2^31 - 1) From: pollita@php.net (Sara Golemon) Ilia Alshanetsky wrote: > Could you not treat a very large integer as a double? We do that in a few > areas of the code already. > Treating it as a double is exactly what json_decode() *currently* does, and it's the problem I'm trying to work around by leaving it in string form. When a large integer is cast as a double, it looses precision, and 1234567890123456789 might suddenly look like (for example) php -r 'var_dump((float)"1234567890123456789" float(1.2345678901235E+18) We've now lost the lowest four digits of this number. For a sum/average/difference type number, that imprecision may be acceptable, but for a specific ID used in (for example) a database, it means that 9,999 of every 10,000 records all wind up correlating to the same incorrect ID. -Sara