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

[Owen Taylor <otaylor redhat com>]

Mark Murnane <Mark Murnane Sun COM> writes:

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

Do Tim's recent changes fix this problem for you? 
 
> 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.

No they can't. If you find instances of this, they simply need to be
fixed, and not by using longs instead. I would be shocked if anything
of this sort turned up in GTK+...

> Perhaps we could compromise on a GPOINTER_TO_SIZE macro
> instead?  Owen suggested this and it might keep everyone happy.  

A GPOINTER_TO_SIZE macro may be a good idea, but not because anybody
is using GPOINTER_TO_INT to stuff macros into integers...

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

Unless it is _likely_ that this will happen, this is fine. A few collisions
are expected for a hash table. I suppose if an operating system did
something like returned the results of each malloc() aligned on 4 gig
boundaries or something, we'd have problems. But this doesn't strike
me as a likely scenario.
 
> 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.  

I think people have to be aware of the pitfalls here or they'll mess
up in other ways. Is 

int mycompare (gconstpointer a, gconstpointer)
{
 return *(int *)a - *(int *)b;
}

A valid compare function on a 32 bit machine? 

Not if and b are actually signed integers... I'm not sure that
restricting to -1, 0, 1 is necessary, but some notes in the
documentation might help.

Regards,
                                        Owen