Re: Crash processing g_object_new arguments

[Jim George <jimgeorge gmail com>]

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,  <erniew 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