nih-dbus-tool expects output integer arguments to use non-zero to denote success

[James Hunt]

If nih-dbus-tool is passed a snippet such as:

<method name="Foo">
    <arg name="myint" type="i" direction="out" />
</method>

... the code that nih-dbus-tool generates in proxy mode contains a block like this:

    do {
        __label__ enomem;

        /* Demarshal a int32_t from the message */
        if (dbus_message_iter_get_arg_type (&iter) != DBUS_TYPE_INT32) {
            dbus_message_unref (reply);
            nih_return_error (-1, NIH_DBUS_INVALID_ARGS,
                              _(NIH_DBUS_INVALID_ARGS_STR));
        }

        dbus_message_iter_get_basic (&iter, &myint_local);

        dbus_message_iter_next (&iter);

        *myint = myint_local;
    enomem: __attribute__ ((unused));
    } while (! *myint)

This is correct, but assumes that if *myint is zero, that is an error condition. Whilst that would seem to be the only reasonable approach for the code nih-dbus-tool generates to take, this may not be a reasonable assumption from the client+servers perspective.

A possible solution would be to simply document this behaviour as a limitation of nih-dbus-tool.