On Thu, 01 Jun 2000 13:14:39 CDT, the world broke into rejoicing as
John Goerzen <[EMAIL PROTECTED]> said:
> 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!
No big problem; I would, by the way, suggest that you look to
/usr/include/glib.h rather than anywhere else.
GnuCash _does_ have a forcible dependancy on glib, so that depending on
the "force-a-particular-width" typedefs in /usr/include/glib.h does not
add any additional dependancies to GnuCash as a whole.
I'd tend to think it a good idea to go through the code base and
introduce rather a lot of "gint32" values throughout...
--
[EMAIL PROTECTED] - <http://www.ntlug.org/~cbbrowne/>
"Optimization hinders evolution." -- Alan Perlis
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
