Bug #49764 [Com]: number_format() fails (randomly?)
Edit report at https://bugs.php.net/bug.php?id=49764edit=1 ID: 49764 Comment by: ricardojdn at gmail dot com Reported by:tec at baufi24 dot de Summary:number_format() fails (randomly?) Status: Wont fix Type: Bug Package:Math related Operating System: Windows PHP Version:* Assigned To:pajoye Block user comment: N Private report: N New Comment: I've created a new PHP5.3.1VC9-windows compilation with mssql and the problem has been solved. My PC: Windows 7 + Apache 2.2 + SQLServer2008 + (my)PHP5.3.1VC9 Previous Comments: [2012-03-08 11:28:03] paj...@php.net VC9 builds do not have this problem anymore and we do not support VC6 anymore. [2010-11-18 07:19:00] tec at baufi24 dot de 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/ [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 #49764 [Com]: number_format() fails (randomly?)
Edit report at http://bugs.php.net/bug.php?id=49764edit=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.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 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
Bug #49764 [Com]: number_format() fails (randomly?)
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 a
Bug #49764 [Com]: number_format() fails (randomly?)
Edit report at http://bugs.php.net/bug.php?id=49764edit=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 New Comment: 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 Previous Comments: [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 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
Bug #49764 [Com]: number_format() fails (randomly?)
Edit report at http://bugs.php.net/bug.php?id=49764edit=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.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 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
Bug #49764 [Com]: number_format() fails (randomly?)
Edit report at http://bugs.php.net/bug.php?id=49764edit=1 ID: 49764 Comment by: derek dot ethier at humber dot ca Reported by: tec at baufi24 dot de Summary: number_format() fails (randomly?) Status: Assigned Type: Bug Package: Math related Operating System: Windows Server 2003 RC2 PHP Version: 5.2.11 Assigned To: pajoye New Comment: 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 Previous Comments: [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. [2009-12-21 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2009-12-13 18:13:29] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-10-12 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. 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=49764edit=1
Bug #49764 [Com]: number_format() fails (randomly?)
Edit report at http://bugs.php.net/bug.php?id=49764edit=1 ID: 49764 Comment by: derek dot ethier at humber dot ca Reported by: tec at baufi24 dot de Summary: number_format() fails (randomly?) Status: No Feedback Type: Bug Package: Math related Operating System: Windows Server 2003 RC2 PHP Version: 5.2.11 New Comment: 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. Previous Comments: [2009-12-21 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2009-12-13 18:13:29] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-10-12 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2009-10-04 18:03:36] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-10-04 08:55:27] tec at baufi24 dot de Description: Using number_format will sometimes produce a very hard error. This phenomenon is not persistent. Sometimes i will see that, but i dont know what conditions are necessary to reproduce Reproduce code: --- $value = 2900; echo Unformated: .$value.br /; echo Using number_format: .number_format($value, 2, ',', '.').br /; echo Crosscheck: .number_format(2900, 2, ',', '.').br /; Expected result: Unformated: 2900 Using number_format: 2.900,00 Crosscheck: 2.900,00 Actual result: -- Unformated: 2900 Using number_format: 2.8:0,00 Crosscheck: 2.8:0,00 -- Edit this bug report at http://bugs.php.net/bug.php?id=49764edit=1
