Edit report at http://bugs.php.net/bug.php?id=49764&edit=1
ID: 49764 Comment by: codeslinger at compsalot dot com 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 New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ [2010-04-16 11:15:26] paj...@php.net I will ask our test team to try to reproduce it. ------------------------------------------------------------------------ [2010-04-15 20:24:54] derek dot ethier at humber dot ca I've been experiencing a similar problem on 5.2.12 and 5.2.13 on a Windows Server 2003 environment (not R2). I haven't been able to nail down any sort of specifics as it happens so randomly. The only consistent element seems to centre around odd numbers (specifically with 9) format incorrectly in a similar manner to the one originally described (with a colon in the middle). I'm not sure if this helps at all, but I thought I'd add a comment anyway. ------------------------------------------------------------------------ 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
