Hi, As some of you may have seen a few weeks ago on gnome-hackers, myself and Michael Myburgh at Sun having been working to make sure that gnome libraries will run on 64-bit platforms. Our first candidate was glib. We've completed the changes now and we'd like you guys to evaluate - and hopefully integrate - the changes. It has been mentioned in more than one e-mail that Gnome has no problems on 64-bit platforms, namely Alpha based systems. While this may be true, there are many cases where 64-bit errors could occur but through luck have not. In our own case we found memory alignment problems when using a 64-bit version of gmodule. As a quick preamble, I'll just mention that these changes were made to fit the LP64 model of code generation. In this model, longs, size_t, ssize_t and pointers are 64-bits long. This model is currently used by UltraSPARC, Alpha(AFAIK)and Intel's Itanium. The bulk of the changes relate to making glib capable of handling 64-bit strings. This may not exactly occur often, but Y2K caught a lot of people off guard :-) This move makes sense for another reason. On both the Solaris and Linux platforms, many of the string library functions are specified as returning size_t values, or taking them as parameters. It makes sense then that glib use the equivalent value rather than relying on the fact that longs, pointer and ints are all basically the same thing on a 32-bit platform. Another significant change we had to make was to change the use of all GPOINTER_TO_[U]INT macros. We introduced a GPOINTER_TO_[U]LONG macro wherever the integer version was used. While we can't change every application that makes use of these macros, we would encourage it. It'll make apps more reliable as 64-bit computing becomes more widespread. A change which we would also like to make concerns the definition of gsize and gssize. These are currently defined to be 64-bit values when on a 64-bit platform. I'd like to come up with some way to redefine this as something like size_t and ssize_t, but I found that not every platform know what ssize_t is. Your input on this would be appreciated. The principle reason to make this change is to facilitate developers who write 64-bit code on 32-bit platforms. This situation is already common on Solaris, where developers use the same libraries always, but link in the 64-bit libraries if they want them. A final change we made was to redefine GHashFunc to return a glong. This was done due to the use of functions like g_direct_hash, which basically return a pointer. This causes the same loss of data that the GPOINTER_TO_[U]INT macros cause. Similarly, GCompareFunc was modified. The API does not specify what the return value is. People may try to interpret this value and if the are dealing with strings, large numbers or pointers, they may lose data. Most of these changes should have little, and more probably, no impact on current 32-bit platforms. The equivalence of long, pointer and ints ensures that. To reassure you all, I have compiled glib from HEAD with the patch applied. The compile completed successfully and testglib, testgruntime and testgmodule all ran successfully. Apologies for the size of the diff, but I thought a single diff would be best. Finally, I'd like to say these changes may not be perfect or complete. Something may have been overlooked, or a change may have been made that somebody with better knowledge than myself can say is unnecessary. Feel free to let us know. Thanks, Mark ================================== Mark Murnane Desktop, Applications & Middleware Sun Microsystems Ireland ==================================
Attachment:
glib-64bit-changes.diff.gz
Description: GNU Zip compressed data