ID: 43053
Updated by: johannes@php.net
Reported By: owner at dragon-hearts dot net
Status: Critical
Bug Type: Scripting Engine problem
Operating System: Centos4
PHP Version: 5CVS-2007-10-25
-Assigned To:
+Assigned To: dmitry
New Comment:
Dmitry, what's your opinion on this?
Previous Comments:
------------------------------------------------------------------------
[2008-08-14 21:01:04] int-e at gmx dot de
That was just a small whitespace problem (5.2.6 had a lonely tab on an
otherwise empty line in main/snprintf.c. it's gone in 5.3.0alpha1). Try
this one.
http://int-e.home.tlink.de/php/php-5.3.0alpha1-printf.patch
------------------------------------------------------------------------
[2008-07-02 04:43:28] int-e at gmx dot de
In the hope that this speeds up fixing the bug, here's a version of
above patch that applies cleanly against php 5.2.6. The formatting of
the code in question is different in the subversion trunk, but it's the
same otherwise. At least that's how it was two months ago.
http://int-e.home.tlink.de/php/php-5.2.6-printf.patch
(use patch -p1 to apply)
------------------------------------------------------------------------
[2008-06-30 14:38:33] admin at shadowops dot net
This bug is not limited to the Round() and related commands.
I have been hit by it and it has caused many issues with MYSQL and
values entered into the DB.
1200000 in debug mode prints as 1.2E+6 this is why in the DB it simply
+1 insted of 1200000
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
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