[patch] generate marshallers and metadata from dbus-glib-tool
walters at verbum.org
Tue Nov 9 17:59:22 PST 2004
On Tue, 2004-11-09 at 17:37 -0500, Paul Kuliniewicz wrote:
> I've made some relatively minor changes to my patch for generating
> marshallers for the GLib bindings. The updated patch and a
> demonstration of its usage are attached.
Cool, works for me. We need to get Oliver's signal work added; after
that it looks like we're mostly blocked on GObject introspection, right?
> Before making some of the other changes Havoc suggested, I'd like to get
> a little feedback on my plans on how to handle OUT parameters. In
> particular, the question of how to clean them up. If a method returns a
> string, the type system doesn't indicate whether the string was
> dynamically allocated (in which case the marshallers must free it) or
> statically allocated (in which case the marshallers must leave it
To be a bit more precise, the distinction is ownership of the memory,
not dynamic/static allocation. One approach would be to just always
assume the marshallers own the string, but that would kind of suck if
you were were exporting say a text widget with a GetBuffer method, that
would normally return a const pointer to a potentially very large
buffer. On the other hand - DBusMessage already copies everything you
stick in to it (something I think we should not do as an option for byte
 at least, but that's another issue).
> The patch currently allows the XML file to explicitly specify which
> function, if any, to use to free the return value. This works fine in
> the single-OUT-value case, but gets rather unwieldy if you allow
> multiple OUT parameters. Plus, I don't think you really need the full
> generality of using *any* function to release the value -- it should be
> pretty safe to assume g_free is the one to use.
My guess is that assuming g_free is fine.
Nice work! I'm really inteterested in getting the glib bindings going
well; a lot of work blocks on that.
More information about the dbus