ID: 43053 Comment by: sweiss at stylesight dot com Reported By: owner at dragon-hearts dot net Status: Verified Bug Type: Scripting Engine problem Operating System: Centos4 PHP Version: 5CVS-2007-10-25 New Comment:
You guys *have* to make changes like this more explicitly stated... It took forever to even realize the problem we were having lay with PHP and not the Javascript it was printing it out to - I definitely read the changelog and definitely did not pick up on the fact that all my numbers were going to suddenly come out in this totally useless format now. *Seriously Frustrating* - Couldn't this have just been an ini option for the people that wanted it? Previous Comments: ------------------------------------------------------------------------ [2008-04-18 13:07:41] rbro at hotmail dot com Thanks for your help - that definitely seems to fix the problem. I manually applied your changes since I wanted to test it against the PHP 5.2.5 source, but I'm getting consistent output now when working with floats. ------------------------------------------------------------------------ [2008-04-18 01:34:28] int-e at gmx dot de Here's a patch that fixes the problem. http://int-e.home.tlink.de/php/php-printf.patch There are three changes here: 1) get rid of a hack in zend_dtoa() that sometimes kept trailing zeros (which caused the inconsistent behaviour between printing 1200000 and 1300000) 2) change php_gcvt() to switch to E format for large numbers if the number wouldn't fit into precision digits. 3) update a few tests to reflect the change to the precision semantics. I believe that in each of these cases, the test was flawed. Note that a precision of 14 (the default) means that 15 digit numbers should be printed in E notation, at least that's how I read the sprintf documentation. ------------------------------------------------------------------------ [2008-04-15 22:37:33] rbro at hotmail dot com Your examples work correctly for me in PHP 5.2.1, so I'm not sure if the issue was caused by change you mentioned or something else, but it definitely happens for me in PHP 5.2.2 and later. ------------------------------------------------------------------------ [2008-04-15 20:43:16] marek dot chodor at gmail dot com on PHP Version 5.2.6RC1-pl1-gentoo and PHP 5.2.4 Fedora7 the same problem $ php -r "echo 120000000;" 120000000 $ php -r "echo (double)120000000;" 1.2E+8 $ php -r "echo (int)(double)120000000;" 120000000 It could be related to this change in PHP 5.2.1: # Changed double-to-string utilities to use BSD implementation. (Dmitry, Tony) ------------------------------------------------------------------------ [2008-04-15 09:08:48] ali at adcworks dot com I am receiving longs via SOAP responses which represent IDs of accounts. Due to some issue with PHP and long values when we retrieve accounts using the same IDs we receive, we get other peoples' accounts back - not good! I have found the core problem and the snippet of code below shows that the correct ID of 285000000003622757 is transformed into the incorrect ID of 285000000003622752 (last number goes down 5). <?php $long = 285000000003622757; function f0($long) { return $long; } function f1($long) { return sprintf ( "%.0f", $long ); } function f2($long) { return number_format($long, 0, '.', ''); } ?> <h1>F0 (no formatting) </h1> <?= f0($long) ?> <h1>F1 (sprintf) </h1> <?= f1($long) ?> <h1>F2 (number_format) </h1> <?= f2($long) ?> OUTPUT ====== F0 (no formatting) 2.85000000004E+17 F1 (sprintf) 285000000003622752 F2 (number_format) 285000000003622752 ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/43053 -- Edit this bug report at http://bugs.php.net/?id=43053&edit=1
