Re: More 64bit issues (Was: Re: gtype.h broken for 64-bit)

[Tim Janik <timj gtk org>]

On Mon, 26 Nov 2001, George wrote:

> On Sun, Nov 25, 2001 at 04:49:52PM -0500, Havoc Pennington wrote:
> > > ok, thanks for tracking this down. i'm about to comit the following fix:
> > 
> > Looks perfect, thanks!
> 
> There are other 64bit issues.  Please check: 
> http://bugzilla.gnome.org/show_bug.cgi?id=65367
> 
> There is a patch there.  Basically there were some GPOINTER_TO_UINT and
> GUINT_TO_POINTER usage to convert GType to/from gpointer which is wrong,
> it should be a plain cast.  Also there was a messup with format strings
> on some warnings.
> 
> In any case, with the fundementals fix and with the patch above, I can
> actually get programs to run again without coring on the alpha.
> 
> I wonder why Havoc hasn't noticed this on ia64?

hm, the first question that comes to mind here is:
why didn't gcc catch ("%u", (gsize) x) in the first place, i.e.
on x86?
the answer is, because we define gsize to guint32 if their sizes
match.
unfortunately, doing #define gsize gulong if sizeof(gsize)==sizeof(gulong)
introduces new problems, such as:
  #include <malloc.h>
  void (*my_malloc) (size_t size) = malloc;
warns about invalid pointer type assigment, because size_t is defined
to int in standard headers for x86 as well ;(
while i think that #define gsize gulong would have been the right
thing to do to deal with a type that changes sizes on 32/64 bit platforms,
it seems we can't do this here.

so, i'm now planning to have:

#if     GLIB_SIZEOF_LONG == GLIB_SIZEOF_SIZE_T
typedef gulong                          GType;
#else   /* hm, shouldn't happen? */
typedef gsize                           GType;
#endif

any better ideas?

> 
> George
> 

---
ciaoTJ