Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:46721 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 92302 invoked from network); 14 Jan 2010 00:30:09 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Jan 2010 00:30:09 -0000 Authentication-Results: pb1.pair.com header.from=ralph@smashlabs.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=ralph@smashlabs.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain smashlabs.com from 67.15.58.61 cause and error) X-PHP-List-Original-Sender: ralph@smashlabs.com X-Host-Fingerprint: 67.15.58.61 openrce.org Linux 2.6 Received: from [67.15.58.61] ([67.15.58.61:55230] helo=users.smashlabs.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id EA/4C-00773-0956E4B4 for ; Wed, 13 Jan 2010 19:30:08 -0500 Received: (qmail 4031 invoked from network); 13 Jan 2010 18:30:01 -0600 Received-SPF: none (no valid SPF record) Received: from ip70-171-83-210.no.no.cox.net (HELO ralph-macbook.local) (70.171.83.210) by smashlabs.com with (DHE-RSA-AES256-SHA encrypted) SMTP; 13 Jan 2010 18:30:00 -0600 Message-ID: <4B4E658C.7080908@smashlabs.com> Date: Wed, 13 Jan 2010 18:30:04 -0600 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061207 Thunderbird/1.5.0.9 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: internals Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Int to float precision loss in 64bit environment From: ralph@smashlabs.com (Ralph Schindler) Hey list: I noticed an issue today running our ZF unit tests, it primarily came down to this issue: On 32 bit environments .. ~# php -r "var_dump(PHP_INT_MAX+1 > PHP_INT_MAX);" .. will return true, whereas in 64bit environments, this returns false. In talking with Stas, it seems that since PHP_INT_MAX+1 is pushed into a (float) and since float values are stuffed into 52bit mantissa / 11 bits for exponents, we are loosing some precision. That lost precisions is causing the above to fail in one platform, and work in another. Is this noted somewhere? Is there a workaround? Or, is this something that can be fixed for 64 bit platforms (somehow)? This is not a big issue for us since (it seems) it's strictly a value that is being created for unit testing and I am not sure if it's something people use in code, or even see in the wild in general. I can get around it by ensuring the actual value is large enough to change the minimal precision value using PHP_INT_MAX+1025. It't not until you've pushed past a 1024 buffer/(integer loss in precision?) until things start working again as expected: ~# php -r "var_dump(PHP_INT_MAX+1 > PHP_INT_MAX);" bool(false) ~# php -r "var_dump(PHP_INT_MAX+1024 > PHP_INT_MAX);" bool(false) ~# php -r "var_dump(PHP_INT_MAX+1025 > PHP_INT_MAX);" bool(true) Any information would be great. Thanks, Ralph Schindler