bool type

[Tako Schotanus]

Hi, I don't care too much, but I'm curious as to the exact nature of the
problem you're describing. In your explanation I don't see anything that
seems like a big problem. The only thing that seems worth knowing to be
able to decide for one solution or the other is your final remark "which
will unavoidably leak into the C API a little bit" but there's no further
explanation.

Now I don't think you should listen to my opinion anyway (due to the fact
I have very little practical experience with DBus so far) but I'm curious
enough to want to know the reason behind the change :-)

Cheers,
 -Tako


-- 
T. Schotanus
Sr. Software Engineer
www.codejive.org

> Hi,
>
> I don't know what to do with bool types. On the wire they are bytes,
> because it seems really wasteful to use 32 bits.
>
> However, then dbus_bool_t is currently an int.
>
> What do you expect here:
>  dbus_bool_t v_bool;
>  dbus_message_iter_get_value (&iter, &v_bool);
> or
>  unsigned char v_bool;
>  dbus_message_iter_get_value (&iter, &v_bool);
>
> Or the following:
>
>  const unsigned char *array;
>  int n_elements;
>  dbus_message_iter_get_fixed_array (&iter, &array, &n_elements);
>
> Which returns a const pointer into the message, and thus must return an
> array of bytes if the wire representation is bytes.
>
> And here's another problem:
>
>  dbus_message_iter_append_args (&iter, DBUS_TYPE_BOOLEAN, TRUE,
>                                 DBUS_TYPE_INVALID);
>
> Where TRUE will be 32 bits normally. I believe this is why gboolean in
> glib was changed from char to int, though I'm not sure I remember that
> far back.
>
> My inclination is to change the wire representation to be 32 bits,
> define dbus_bool_t as int32, and always use dbus_bool_t as the type that
> is returned or passed in for bools.
>
> In the old D-BUS type system, 32-bit bools would double their usual size
> from
>    1 typecode, 1 value, 2 padding = 4
> to
>    1 typecode, 3 padding, 4 value = 8
> However, with the new type system, it's more like:
>    1 value, 3 padding = 4
> to
>    1 value = 4
> (this is all assuming the bool is followed by a 4-aligned type, which is
> the most common case; there's no padding if it's followed by a 1-aligned
> type).
>
> We probably don't care about the size of single bool args anyway, since
> there won't be more than a small number of them per message. But if we
> did care, it's not really a meaningful difference anymore.
>
> The real reason I originally used byte and not int32 for bool was for
> arrays, where using an int32 means 32x overhead. However, I'm now
> thinking:
>  - 8x overhead is still pretty bad if you have enough bools to
>    start caring about overhead
>  - people who are worried about overhead can use a bit vector
>    class from their favorite programming language and stuff
>    it in a dbus byte array
>  - when was the last time you used a bool array anyhow?
>    I don't think I do this very often.
>
> If this doesn't make sense and someone feels we should keep bool == char
> on the wire (which will unavoidably leak into the C API a little bit),
> speak now.
>
> Havoc
>
>
> --
> dbus mailing list
> dbus@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
>