#29064 [Asn]: Exact numeric/decimal/money datatypes lose precision

ID: 29064 Updated by: thekid@php.net Reported By: daniel dot beet at accuratesoftware dot com Status: Assigned Bug Type: Sybase-ct (ctlib) related Operating System: Windows 2000 Server PHP Version: 4.3.7 / HEAD Assigned To: thekid New Comment: I fixed this bug locally but still have quite an amount of other bugfixes / improvements lying around, which I don't want to separate from this. Maybe you'd like to test the complete patchset available at http://sitten-polizei.de/php/sybase_ct.diff (HEAD) http://sitten-polizei.de/php/sybase_ct4.diff (PHP_4 branch) As soon as I've tested the other changes enough, I'll commit everything to CVS (should be in a couple of days) Previous Comments: ------------------------------------------------------------------------ [2004-07-11 15:35:00] thekid@php.net Testcase now available at: http://sitten-polizei.de/php/bug29064.phpt (place in ext/sybase_ct/tests and run make test TESTS=ext/sybase_ct, be sure to edit ext/sybase_ct/tests/test.inc and supply correct DS_QUERY and credentials there) ------------------------------------------------------------------------ [2004-07-11 15:29:26] thekid@php.net Seeing that the PHP version in the Bug report was 4.3.7, I also made a patch against the PHP4 branch. http://sitten-polizei.de/php/float_precision-php4.diff ------------------------------------------------------------------------ [2004-07-11 13:56:26] thekid@php.net Have a look at the following: http://sitten-polizei.de/php/float_precision.diff This accomplishes the "best-result"-semantics described in my above comments. I use EG(precision) to check where we overflow - as I understand, this value is the precision to which floats are still "correct". ------------------------------------------------------------------------ [2004-07-11 13:26:01] thekid@php.net Btw: Sybase-CT behaves like PHP itself (due to the afforementioned reason): $ php -r 'var_dump(12345678901234567890123456789012.123456);' float(1.23456789012E+31) (the above result depends on the precision set: $ php -dprecision=20 -r 'var_dump((float)"12345678901234567890123456789012.123456");' float(1.234567890123457E+31) ------------------------------------------------------------------------ [2004-07-11 13:19:19] thekid@php.net Thank you for your bug report, first of all. > /* numerics can overflow real and long types, return as a string */ I would not like to do that in general. I use the convert_scalar_to_number() function (defined in Zend/zend_operators.c) on numerics to achieve the "best" result, which is: * If the scale is 0 and if it fits into an int, make it an int, make it a float otherwise (this simulates PHP's behaviour when overflowing LONG_MAX) * If the scale is not 0, make it a float Now what I forgot was that a float may not be able to hold the number returned, therefore my suggestion would be to check for float overflow and thus add this to the above list: * If a float overflow is detected, make it a string How's that? ------------------------------------------------------------------------ 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/29064 -- Edit this bug report at http://bugs.php.net/?id=29064&edit=1