[PATCH] Add a parameterised gtype for structs

[Ole André Vadla Ravnås]

Hi,

Here's a quick fix for a bug introduced in dbus-binding-tool by the
struct patch. Basically the argument list for generated calls to
dbus_g_type_get_struct ("GValueArray", ...) wasn't terminated.

Regards,
Ole André


On 2/7/06, Rob Taylor <robtaylor at floopily.org> wrote:
> [mm, forgot to reply to list.. damn mornings... ]
>
> Havoc Pennington wrote:
> > Ideally we could find a way to use the code in
> > dbus-marshal-recursive-util.c to also test the glib stuff. It exports a
> > function already (grep for generate_bodies) that returns all its test
> > cases as raw data; if we could use that (or export some slightly
> > different function) then the glib test suite could just get each test
> > case, round-trip it through the glib bindings, and see if it gets back
> > the same bytes as the original test case. Really this would be a pretty
> > airtight way to test any binding.
>
> That's a very good idea, I think one thing we discussed with splitting
> out the bindings was a unified way to unit test each binding, this seems
> a good way of going about it.
>
> > On the bigger picture of the patch - I think we had a discussion about
> > how to do structs a while back? Any writeup of why this patch does it in
> > this way vs. others, general notes on the approach, etc.?
>
> Well, as I saw it, there were two options for actually making the
> bindings capable of marshalling every signature:
> 1) produce a true bijection from the glib type system to the dbus type
> system
> or
> 2) modify all marshalling recursion to also simultaneously descend the
> dbus signature and marshal according to the signature.
>
> Now obviously the python and perl bindings use 2), as its more natural
> for those languages to say how something should appear on the wire than
> force users to do odd things to be strictly typed.
>
> However for glib, strict typing is completely natural, so 1) is the more
> obvious choice. 2) would also have meant that several interfaces would
> have to have changed (g_proxy_call, g_proxy_add_signal, etc), and that
> we'd also have to store property and signal type information in
> DBusGObjectInfo. TBH, it just seemed alien to the current modus operandi ;)
>
> Another option that I quickly discarded due to its foul nature ;) was to
> modify all of the dbus-gsignature code so that it could also follow data
> as well as the type in order to discover signature for structs as they
> existed before this patch, but not only is this horrible, as I'm sure
> you'll agree, it also doesn't help for the cases where, say an array is
> empty.
>
>
> > Also, I asked Colin if he would take a high-level look at it.
>
> That would be brilliant - it was slightly scary doing this without his
> input! ;)
>
>
> Thanks,
> Rob Taylor
>
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 06-dbus-binding-tool-fix-varargs-termination.patch
Type: text/x-patch
Size: 436 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20060209/f13a57d0/06-dbus-binding-tool-fix-varargs-termination.bin