On Monday 13 February 2006 6:41 pm, Chris Shoemaker wrote: > [Neil, please remember to cc gnucash-devel for changeset discussion.]
(glitch with the mail folders, the CC: line put it into a different location and I didn't notice - v.busy right now.) > > Wrong changeset - there have been improvements since then. See r13255 > > Yes, I know. OK, as long as we're on the same version. > Perhaps I > should have replied to the the 4th changeset. Nah, just me being hasty - maybe if you'd snipped the bit about the original changeset number.... :-) > > You can't fix one without the other because the first bug exists as the > > original contributor's solution to the second. > > I disagree. However, even if this were true, the fix is insufficient, > since the second bug still remains, so it wouldn't have been solved by > this replacement solution. The failure is avoided but the recursive loop at the centre of the problem does appear to be a key component in the overall calculation. > I understand from your other email (also not cc'd to -devel) that you > don't have the time to fix this at the moment. So, I'll go ahead and > complete steps 1-3 of my recommendation, so then the code will be > ready for you or whomever to debug the infinite-loop when they get a > chance. Step 1 reverses what Christian recommended and I agreed - to use an assertion to indicate that a zero value is not acceptable. A bug it may be, but a zero value will crash the code - as is. As a bug, it deserves an assertion to prevent it OR a complete reworking to avoid it. I can't see that removing the assertions *without* fixing the infinite loop does anyone any favours. If you're willing to fix the problem so that it *can* deal with a zero interest rate, go ahead - just remember to remove the warning from the dialogue. That is the API - the calculator does insist that the interest rate ENTERED by the user is non-zero. (Try it.) However, the original code relied on that safeguard and did not protect against generating a zero rate internally. Fatal flaw that resulted in a very ugly hack to call exit(1) - the original source of the bug. I did say at the time that the exit(1) call was presumably put in by the original author because s/he saw no other way to handle it. It deserved to be removed. The error is only for 0.00000000 because it centres on division by zero. Anything other than zero will simply raise a number. Zero itself raises NaN and that's when the calculator hangs gnucash. AFAICT, there is a recursive loop that tries to endlessly calculate 1/0 instead of accepting that it cannot be done (safely). As long as the number is within the limits of a double, we're OK. 1/0 is not, 1 divided by 0.0000000001 is. Do we really need any more accuracy than that? Unless the internal code is rewritten to safely handle zero, then, yes, IMHO zero is an assertion failure - a critical failure that deserves to get the calculator loop shutdown urgently. The fix allows the calculator code to shutdown without affecting gnucash - indeed it allows a zero value to be demonstrated without being explicitly supported. It did NOT deserve to shutdown gnucash. That's now fixed - anything else is a bonus. (If there's time.) -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgpudKJ4sumG4.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
