Re: [gtk-list] Re: How to use a gpointer?




On Fri, 5 Mar 1999, Tim Janik wrote:

> i don't frankly understand your argumentation. all the configure.in
> tests glib uses have been written by the GLib team people, and we
> have not yet encountered something to check for with regards to
> storing ints in pointers. we can certainly test for sizeof(int)>=4
> and sizeof(gpointer)<=sizeof(glong) (sizeof(long) is guaranteed to
> be >= sizeof (int) by the C standards) and special case that in glib.h
> or glibconfig.h, but i don't see a need for such a test when we know
> that it'll always be passed successfully. we can simply "hard-code"
> typedef void* gpointer; typedef int gint; typedef long glong; in that
> case, which is in fact what we do right now.

OK, here is the problem:

It has been asserted that using Glib, a gint can be safely converted to
gpointer and back. For this to hold water, something needs to make it so.

This "something" cannot be C, because conversions between pointers and
integral types are implementation-defined. And it cannot be Glib itself,
because Glib doesn't even try. What remains is perhaps to document that
Glib is only portable to implementations where certain conditions are
satisfied.

As to how it should be tested for: these things are documented by the
vendor, that's what implementation-defined means. So for known compilers,
it can be handled as what the autoconf documentation calls an "unguessable
feature". For others, checking the sizes and hoping for the best will
perhaps have to do to.

Frankly, I don't see any point in "typedef int gint" if the intention is
to create a general-purpose integer type with exactly the same properties
as the already existing general-purpose integer type. The same goes for
"typedef long glong" et al. The definitions in glibconfig.h make a little
more sense.

Ulric



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]