On 11/17/2014 05:36 PM, Eric Blake wrote:
Use of an 'int' to represent a 'bool' value is
confusing. Just
because dbus made the mistake of cementing their 4-byte wire
format of dbus_bool_t into their API doesn't mean we have to
repeat the mistake. With a little bit of finesse, we can
guarantee that we provide a large-enough value to the DBus
code, while still copying only the relevant one-byte bool
to the client code, and isolate the rest of our code base from
the DBus stupidity.
[Have I ever mentioned that the assymetry between type promotions
of values passed through var-args on setting, vs. no promotions
when passing pointers through var-args for getting, makes life
awkward, not just for DBus interactions, but also for printf vs.
scanf? Then again, using scanf is often the wrong thing to do...]
* src/util/virdbus.c (GET_NEXT_VAL): Add parameter.
(virDBusMessageIterDecode): Adjust all clients.
* src/util/virpolkit.c (virPolkitCheckAuth): Use nicer type.
* tests/virdbustest.c (testMessageSimple, testMessageStruct):
Test new behavior.
-# define GET_NEXT_VAL(dbustype, vargtype, fmt)
\
+# define GET_NEXT_VAL(dbustype, member, vargtype, fmt) \
do { \
dbustype *x; \
+ DBusBasicValue v; \
Blech. DBusBasicValue wasn't defined in the older dbus-types.h from
1.1.2 as shipped on RHEL 5, causing a compilation failure there. I'm
working on a fix...
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org