[patch] generate marshallers and metadata from dbus-glib-tool

Colin Walters 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
> alone).

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 mailing list