Hi,
I have been doing some investigation to figure out why gnucash is working on
my i386 but getting confused on the alpha.
I have come up with a few findings. I guess I may be the first
one trying to use it on a 64-bit platform so I will try to send y'all some
patches ASAP.
Anyway, the code seems to incorrectly assume that:
* a long is 4 bytes. On Alpha, it's 8.
* a long is different than a long long. On Alpha, it's not.
* a long is the same as an int.
Anyway, the offendor I have noted here is this. Here is code in
writeTSDate:
tmp = ts->tv_nsec;
XACC_FLIP_INT (tmp);
err = write( fd, &tmp, sizeof(int) );
But look at the corresponding code in readTSDate:
err = read( fd, &nsecs, sizeof(long int) );
Now... on i386, this will work. Why? Because both int and long are 32-bit
on i386. On Alpha, int is 32-bit and long is 64-bit. So, the code writes a
4-byte int and tries to read it back as an 8-byte int. Oops.
If the binary format is going to be preserved, I would *highly* recommend
that at least abolish the usage of int, long, and long long in the code (or
at least the stuff that does file I/O) and instead use macros or typedefs
that explicitly specify the size such that it can be correct on all archs.
I note that Debian includes a stdint.h file with the following macros:
uint8_t
uint16_t
uint32_t
uint64_t
int8_t
int16_t
int32_t
int64_t
What I don't know is how standard stdint.h is, so ports to non-GNU
architectures may not be as easy. However, I suspect that autoconf may have
something available here.
I shall go through the file today and make these changes, and let you know
if it fixes my problems. If it does, I'll send a patch along. Is this
mailing list used for patches? If not, to what address should they be sent?
Alternatively, if there is a newer version in CVS or somewhere, you may want
to patch it yourself (a well-thought-out search & replace should do the
trick), in case there are new places to patch.
Normally I might suggest just fixing this one case. But again, with data as
important as that which is handled by gnucash, I feel that there is zero
room for error and explicitly stating the sizes can go a long way to
improving portability.
Finally, sorry for barraging the mailing list with all these messages :-)
I just tried gnucash yesterday, and was instantly hooked on it. Y'all are
doing a great job, and thanks for a great program!
Thanks,
John Goerzen
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
