Re: GType typedef API/ABI break.

[Murray Cumming <murrayc murrayc com>]

On Fri, 2007-06-22 at 10:05 +0200, Tim Janik wrote:
> On Fri, 22 Jun 2007, Murray Cumming wrote:
> 
> > I sent this to gtk-list by mistake. Re-sending it to gtk-devel-list:
> >
> > I think the recent change to the GType definition is causing linker
> > errors by changing the GType definition from gulong to gsize. We are
> > left with the #else definition that was previously commented as "/* hm,
> > shouldn't happen? */"
> >
> > This is the change:
> > http://svn.gnome.org/viewcvs/glib/trunk/gobject/gtype.h?r1=5497&r2=5560
> > With this ChangeLog entry:
> > http://svn.gnome.org/viewcvs/glib?view=revision&revision=5560
> >
> > This is causing linker errors in almost everything that uses glib and C
> > ++, such as gtkmm and Inkscape, because the parameter type in, e.g.
> >  void get_defs(GType)
> > is part of the function signature.
> >
> > For instance, glibmm's library contains a
> >  void get_defs(unsigned long)
> > But now, when building gtkmm, the linker is looking for
> >  void get_defs(unsigned int)
> > and failing.
> 
> hm, just to clarify explicitely, actual C ABI wasn't broken by
> this change.

I think that's debatable. I'd prefer to be careful than have to argue
over every possible thing this could break.

>  i guess we can workaround the C++ linking issues
> by reintroducing
>    typedef gulong GType;
> if GLIB_SIZEOF_LONG == GLIB_SIZEOF_SIZE_T && defined __cplusplus.
> that'll just leave C++ with bogus warnings about %zu again.

I really don't like the idea of a typedef having one definition for C
and another for C++. It seems destined to break something sometime in
strange and obscure ways.

What does %zu do? What bug does this solve?

-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com