[Gnucash-changes] r13248 - updated see r13255

[Neil Williams]

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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20060213/dfbe6dd5/attachment.bin