Edit report at http://bugs.php.net/bug.php?id=49764&edit=1
ID: 49764 Comment by: adenman at tmea dot org Reported by: tec at baufi24 dot de Summary: number_format() fails (randomly?) Status: Assigned Type: Bug Package: Math related Operating System: Windows PHP Version: * Assigned To: pajoye Block user comment: N Private report: N New Comment: A follow-up: I just created a new site on the server for other testing and the test site does not exhibit this behavior. The test site is completely separate from the main site, but I've copied the settings exactly from the main site and am using the same PHP executable and an exact copy of the php.ini file. I've run diffs on several configuration files and cannot find any differences other than name and site paths. With both sites running on the server, I ran the test several times on each. The main site always gives me '16.:' (wrong) and the test site always gives me '17' (correct). I have no idea what this means, but figured it might be helpful to someone looking into this. Previous Comments: ------------------------------------------------------------------------ [2010-09-01 19:40:46] adenman at tmea dot org I am able to reproduce this. PHP: 5.2.13 OS: Windows 2008 Standard Server, 64-bit (Windows NT WEB2 6.1 build 7600 from phpinfo) CPU: AMD Opteron 6172 Using the test posted by 'adrianv at taly dot net' on bug http://bugs.php.net/bug.php?id=47418 and changing to list whole numbers, I have found the following numbers exhibit this odd behavior: 17, 19, 29, 39 and multiples of ten of these numbers (170, 1700, 17000, etc) They get output as: 16.:0, 18.:0, 28.:0, 38.:0, etc when using the number_format or sprintf functions to format them with decimal places. In addition to number_format and sprintf, I have found that once you do basic math with these numbers and float numbers, even just echoing the result will trigger this bug. The bcmath functions do not exhibit this behavior. Example: $tot = 17; $math = $tot * 1.5; $math = $math / 1.5; $math2 = bcmul($tot, 1.5, 1); $math2 = bcdiv($math2, 1.5, 1); echo $math //outputs 16.:, expect 17 echo $math2 //outputs 17.0, expect 17.0 ------------------------------------------------------------------------ [2010-08-04 13:15:33] codeslinger at compsalot dot com it's not random, it's just very hard to reproduce. only certain specific values will trigger this bug. and the weird thing is that the specific value changes from build to build and with different oses. this bug is a dup of the many other existing reports about this bug. bugs 43487, 47304, 47716, 47732, 51396 etc.. this bug has been encountered in: php 5.2.11, 5.2.12, 5.2.13, 5.2.25, 5.2.26, 5.2.9... it has been found on Windows 2000, Windows XP, Windows 2003, ubuntu, mandriva. This bug has been reproduced both with and without xdebug and/or zend debugger. You want to reproduce this bug???!!! it's very easy, I will give you a one-liner.... install ubuntu 8.0.4 install the standard php that comes with ubuntu 8.0.4 now run this: echo (string) (double) -0.09999999999999999; actual result: -0.0: Note that changing the float percision greatly affects the bug. The thing is that the value is very specific to the actual build and the actual os. For instance it was reported that on Windows nt 5.2 (2003?) the following will fail: echo round(1451,2); actual result: 1450.:0 It has also been reported that using BCMath helps but does not totally solve this problem "3 out of 4 were fixed". But despite all of the above, this bug keeps getting blown off as not repro!!! :-( Consider the following true story: once upon a time, there was a German insurance company sued by a client whoâd lost a lot of money through the insurance companyâs flawed bookkeeping. The insurance company went into a panic and started hunting the bug and were able to prove it was caused by customized software theyâd bought from a German software house. They sued the software house. The software house went into a panic and started hunting the bug further. They were able to prove the bug was actually caused by a flaw in Lotus Symphony. So they sued Lotus. Now Lotus went into a panic and started hunting the bug further. They were able to prove the bug was actually in their C compiler. The compiler was generating a short jump when instead it should have been generating a long jump. ======================= I first encountered this bug in a billing program that I wrote... and so far nobody seems to give a flying fig about fixing this bug. I do not wish to get sued by an irate customer... especially since I am still in start-up mode and have yet to make a single nickel, otherwise I'd be willing to throw some money at php devs if that's what it took to get this fixed. How about somebody else stepping up to the plate, there are some deep pockets out there, come on ibm, microsoft, ??? where is your community spirit? If there is even one single math error in php that is too much. PHP is widely used for eCommerce $ and math accuracy is critical. If I did not have such a huge investment in php code and skills I would have already jumped ship to a different language, as it is, I'm giving it very serious consideration. This situation is very ungood. Just randomly using a different version of php (the latest snapshot) does not solve anything. It has already been established that every single version of php fails with different values. So changing the version will cause that specific value to no longer fail. But until the *cause* of the bug is *actually understood*... we still have lurking failures waiting to zap us. Also the newer versions of php do not come with full library support, and thus *upgrades are impossible* for many of us who need/require those libraries. Just as others have asked, I too shall ask, why is the library support missing??? When will we get it? newer versions of php are worthless without the libraries. ------------------------------------------------------------------------ [2010-06-13 19:35:21] paj...@php.net Nothing changed here. ------------------------------------------------------------------------ [2010-06-13 19:26:12] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ ------------------------------------------------------------------------ [2010-05-13 21:26:19] derek dot ethier at humber dot ca I'm not sure if this will help at all, but outside of confirming this issue with number_format, it now appears as though converting a string to float causing a very similar problem. It seems to happen so randomly, but the only consistent element is that the numbers all have 9 in them. There is an existing bug opened for float that was closed as bogus: http://bugs.php.net/bug.php?id=47716 ------------------------------------------------------------------------ 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/bug.php?id=49764 -- Edit this bug report at http://bugs.php.net/bug.php?id=49764&edit=1
