Edit report at http://bugs.php.net/bug.php?id=49764edit=1
ID: 49764
Comment by: tec at baufi24 dot de
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:
The solution for this bug is to use the right PHP version for Windows
Server. If you use IIS then you have to install a VC9 Version.
http://windows.php.net/download/
Previous Comments:
[2010-11-18 00:07:16] adenman at tmea dot org
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.
[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.0;
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
