I've never come across this problem since I've never used any headers that re-define NULL, nor have I used gobject with C++, but it seems like enough of a "gotcha" that it might make sense to define another constant (G_ARG_TERM?) that always maps to (void *) and use that with all the glib functions that expect a (void *) to terminate the argument list.
-Jim On Mon, Nov 9, 2009 at 8:17 AM, <ern...@comcast.net> wrote: > David Nečas wrote: > >> On Mon, Nov 09, 2009 at 03:24:04AM -0500, Braden McDaniel wrote: >>> OpenvrmlXembedBrowser * const browser = >>> OPENVRML_XEMBED_BROWSER( >>> g_object_new(OPENVRML_XEMBED_TYPE_BROWSER, >>> "control-host-proxy", host_proxy, >>> "control-host-name", host_name, >>> "dbus-thread-context", dbus_thread_context, >>> "expect-initial-stream", expect_initial_stream, >>> 0)); >> >> 0 is not NULL. >> 0 has the size of int while NULL has the size of void*. >> Matters a lot in vararg list. > > This requires clarification. > > 0 *is* NULL, in pointer contexts. In fact, some compilers define NULL > using > > #define NULL 0 > > So using NULL instead of 0, by itself, won't necessarily address the > problem, although it will if the definition happens to be > > #define NULL (void *)0 > > The problem is that this particular NULL appears in the arguments of a > function that accepts a variable number of arguments. The compiler > therefore doesn't know that any particular argument is a pointer and > can't perform the proper type conversion. > > Arguably, the real problem is the design of g_object_new(), and another > way to avoid it is the use of g_object_newv(). > > - Ernie > _______________________________________________ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
