Indeed I wasn't aware of this bug report. It seems as if your patch is fine although I could only look at it briefly.
It does look strange that you need to initialize the resulting scale manually. I thought the BC functions are supposed to take care of returning the results as the right scale.
In any case, it probably makes sense for you to go ahead and commit it.
BTW, is php_str2num() only supposed to work on whole or decimal values? What about exponents? I think you're probably right but I just want to make sure you thought about it.
Thanks,
Andi
At 01:51 PM 2/3/2003 -0800, Sara Golemon wrote:
Andi, Nicos assigned this bug to you a month ago, but since I've seen no activity (and it's entirely possible you didn't know he'd assigned it) I went ahead and took a crack at it. Would you care to give me the go ahead to commit/close for you? ...or tell me to mind my own bugs? :)Patches against PHP_4_3 and HEAD can be found at: http://frankenbox.alphaweb.net/test/php_4_3.bcmath.diff.txt and http://frankenbox.alphaweb.net/test/HEAD.bcmath.diff.txt The idea being to automagically determine the scale of the input numbers so that they are not truncated prior to the op. Then, once the op has been performed, reduce the scale to whatever was requested. The "result->n_scale = scale;" line might look a little dangerous, but since it only comes after lines which create 'result' with a scale of *at minimum* 'scale' it means that 'result->n_scale' will always be >= 'scale' and hence assigning it to 'scale' will always result in a reduction (or no change at all) and bc_num2str won't go looking in undefined sections of the bc_num val. -Pollita P.S. - This one's for you sniper ;)
-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
