On Thu, 01 Jun 2000 12:56:51 CDT, the world broke into rejoicing as
John Goerzen <[EMAIL PROTECTED]> said:
> Hi,
>
> I have a bit more details on the bug report I submitted wrt gnucash
> segfaulting while loading a file.
>
> I tried running gnucash on an i386 machine, loading the same file, and this
> worked perfectly.
>
> Therefore, I think we can conclude that there is some element of 64-bit
> uncleanliness in gnucash's file reading routines. (The platform exhibiting
> the problem is an Alpha running Linux)
>
> Don't ask me where, though :-(
I expect that it's pretty pervasive.
There are LOTS of places where GnuCash uses "int" values, which are
of rather different form on 64 bit architectures than on 32 bit ones.
Result:
You read values into a struct, and find that since parts of it have
changed size, the results no longer align well, which makes any
zero-delimited strings, chewing up bits of what's off, chew up
chunks of the next struct, leading to ill.
What GnuCash probably needs is to _pervasively_ use gint32 rather than
int, gint32 rather than long, and such. Of course, someone has to
volunteer to do the global-search-and-replace on this sort of thing...
I suspect that this change, or something like it, _will_ ultimately
prove necessary. Mind you, I rather think that it would be better
solved by having GnuCash _not_ use a binary data format.
--
[EMAIL PROTECTED] - <http://www.ntlug.org/~cbbrowne/lsf.html>
Why are men like blenders?
You need one, but you're not quite sure why.
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
