Re: Code changes for glib to enhance 64-bit operation

[Mark Murnane <Mark Murnane Sun COM>]

Tim,

I've had a look through your comments on the proposed changes.  As there
are a few issues I haven't included a revised diff here yet.

(Omitted the previous mail.  Don't want this to be too long to read!)


First up, all comments have been removed.  It was as fun taking them out
as it was putting them in :-)


The alignment issue was actually with gobject, not gmodule.  That was a
mistake on my part.   This was the reason for the ForAlignment element
of _GTypeFundamentalInfo in gobject/gtype.h.  We needed this as the
structure was not aligned on an 8 byte boundary otherwise and caused a
core dump on UltraSPARC.


Most of the functions which were using glong for buffer sizes, e.g.
gconvert functions, have been amended to use gssize instead.  I also
modified one other function, g_iconv, to take gsize for some
parameters.  This function was using size_t previously.


The matter of GPOINTER_TO[U]INT and friends is quite important.  Despite
the intention of these macros, they can be used to stuff a pointer into
an int.  Perhaps we could compromise on a GPOINTER_TO_SIZE macro
instead?  Owen suggested this and it might keep everyone happy.  

The GQuark change can be omitted.  Shouldn't cause a problem.


As for the hash functions, while your right that we don't currently use
all of the capacity that a 2^32 value gives, most of these changes are
about making sure that doesn't become a problem.

The loss of resolution in a 64-bit pointer potentially could be an
issue, even if its unlikely.  The memory mapping for an executable,
created at compile time, could lead to an application accessing the
address where the bottom 32-bits are identical.  


The GCompareFunc change can also be omitted.  I have to say I did think
about this one before I made the change.  My reasoning was that the API
documentation was not explicit about the return values.  Again, how
things 'should' be used and the way they are used, don't always match. 
If the API explicitly says that the only return values are {-1, 0, 1}
then there is no reason for the change.  


The change to g_relation_select_tuple was made because I wasn't clear on
just how big a tuple could be.  It may not be likely to be as big as
we're allowing for, but you never know ...


The g_strlcat change was a result of a problem with testglib.  This has
been logged as bug 53933.  Basically Solaris strlcat returns a different
result when dest_size is 0 than the glib implementation.  The change was
to make debugging easier.  I'll back it out.  


The g_snprintf change to return a long is an interesting one I think. 
Your right, it probably should be an int.  That's the way it is on
Solaris too.  Curious, though, that you can pass a buffer > 2^32 bytes
long, but it will only tell you about the first 2^32 characters.


The cast in gutils.c:g_get_any_init() for the sysconf return makes
things clearer.  Changing to a long just necessitates a cast a few lines
later when the buffer size is passed as a parameter to getpwuid_r()
which expects an integer.


The change value_flags_enum_lcopy_value() in gobject/genums.c you have a
point with.  What is the effect though of losing data from the long
value copied in to that location at the end of the function though?


Anyway, that's enough to be going on with for now!

Thanks,

Mark


-------------------------------------
Mark Murnane
Desktop, Appplications & Middleware
Sun Microsystems Ireland
-------------------------------------