Code changes for glib to enhance 64-bit operation


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
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 

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.



Mark Murnane
Desktop, Applications & Middleware
Sun Microsystems Ireland

Attachment: glib-64bit-changes.diff.gz
Description: GNU Zip compressed data

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]