Upcoming GtkTypeFundemental change
- From: Owen Taylor <otaylor redhat com>
- To: gtk-devel-list gnome org
- Subject: Upcoming GtkTypeFundemental change
- Date: Sat, 10 Aug 2002 11:58:56 -0400 (EDT)
It was pointed out by Ross Alexander:
http://bugzilla.gnome.org/show_bug.cgi?id=90400
That the definition of GTK_TYPE_* is wrong ... they are
32bit constants even on 64-bit machines.
(I'm not really sure why this hasn't been noted before... it
may be that some compilers pick a 64-bit type for GtkFundementalType
even though all values in the enumeration fit in 32 bits.)
The obvious simple fix is to change the current:
typedef enum
{
[...]
/* GtkArg types */
GTK_TYPE_CHAR = G_TYPE_CHAR,
GTK_TYPE_UCHAR = G_TYPE_UCHAR,
GTK_TYPE_BOOL = G_TYPE_BOOLEAN,
[...]
} GtkFundamentalType;
To:
#define GTK_TYPE_CHAR G_TYPE_CHAR
#define GTK_TYPE_UCHAR G_TYPE_UCHAR
#define GTK_TYPE_BOOL G_TYPE_BOOLEAN
typedef GType GtkFundementalType;
This has two possibility compatibility effects:
- On 64-bit machines, functions that have GtkTypeFundemental
parameters that were used _only_ for GtkTypeFundemental
values would have worked before, and now will have a different
ABI.
- In C++, any function with a GtkFundementalType parameter
will now be mangled differently.
My intuition is that there is almost certainly no GTK+-2.0 code
out there that has function with GtkFundementalType parameters,
and we shouldn't try to find complicated workarounds to fix
theoretical problems in this area; we should just take the
obvious #define route.
Opinions?
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]