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

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

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

Hmmm, shouldn't we just make gsize a gulong when the size matches?
After all, size_t is long on most systems.

Or is this too much of an API change? (In one sense, it isn't
an API change at all, since it is already _possible_ that gsize
is a long.)

Right now, to supress warnings, you would have to do something
like:

 g_print ("Length of GString is %lu bytes\n", (gulong)string->len);

Which people won't even discover until they try and compile on
a 64-bit system.

Regards,
                                        Owen