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

[Mathieu Lacage <mathieu gnu org>]

le lun 26-11-2001 à 17:18, Owen Taylor a écrit :
> 
> 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.

	- x86-linux-gcc and x86-win32-vc++, size_t resolves to unsigned int.
	- arm-elf-gcc, size_t resolves to unsigned long.

so, it is not long everywhere...

my 2 cents,
Mathieu

> 
> 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
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
> 
-- 
Mathieu Lacage <mathieu gnu org>