> 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
Yes, I think you've definitely hit on the problem here.
When you make your changes, could I ask you to use the
glib definitions:
gint8
guint8
gint16
guint16
gint32
guint32
gint64
guint64
FileIO.c will need to include glib.h, but that is already
included by other .c files so we're not adding a new
dependency. Other systems may not have the stdint.h
headers, but the glib definitions will still be there.
thanks for all your help,
dave
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
