Upcoming GtkTypeFundemental change



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]