Re: More on 64-bit code changes

[Owen Taylor <otaylor redhat com>]

Just following up with some thoughts on your last mail ... 

I'll check over the rest of your patches this morning and verify
with Tim that he's OK to commit them later today. Assuming that
there are no problems, I'll commit the changes after we get
1.3.6 released. (Making that release is currently in process,
so until that gets pushed, I'm holding off on a couple of
API changes.)

Mark Murnane <Mark Murnane Sun COM> writes:

> First up, we've removed all change of GPOINTER_TO_[U]INT macros.  I know
> you'll tell me I told you so, but I check all usage in glib and there
> were no issues.  That's not to say that they aren't misused elsewhere. 
> An example is in the gal library, in util/e-util.c.  The function
> signature indicates two const pointers, and if you pass in two pointers
> to integers then it breaks.  

I don't believe this actually _is_ a misuse of GPOINTER_TO_INT() - of
course, since the function, isn't documented, it's hard to say, but I
believe the intended use of g_int_compare() is:

 list = g_slist_prepend (NULL, 1);
 list = g_slist_prepend (list, 7);
 list = g_slist_prepend (list, 3);

 list = g_slist_sort (list, g_int_compare);

> For future use, we'd like to include GPOINTER_TO_SIZE and
> GSIZE_TO_POINTER if that's okay.
 
That's OK with me; of course, the need for these macros isn't
really as big as 

 pointer = (gpointer)size_variable;
 size_variable = (size_t)pointer;

Should work reasonably portably - unlike GPOINTER_TO_INT, where
the macros depend on the architecture. 

(As a consequence of this, the macros don't need to go in
configure.in, they can go in, say, gmacros.h)
 
> Second up, I've made a change to the implemenation of
> g_hook_compare_ids.  Its not much of a change but the existing
> implementation is not 64-bit safe.  It now basically does the same as
> any GCompareFunc function(even if its not one).  Should anyone be
> interested I've attached a small test program that displays the problem
> on a 32-bit machine.
 
What I'd say is that the existing implementation is not safe at all;
it's not really a 64 bit question.

Regards,
                                        Owen