Expressing large integer values in D-Bus APIs

[Simon McVittie]

On Mon, 17 Jul 2017 at 12:12:09 -0700, Andy Grover wrote:
> If we have a large integer value that might exceed 64 bits, how best to
> expose it on D-Bus? Convert to string? an array of [u64 (high), u64 (low)]?
> An array of 16 bytes and specify endianness?

For arbitrarily large integers, I would recommend putting your favourite
"bignum" encoding (as used in e.g. libgmp and Python 'long') in an array
of whatever smaller integer type seems easiest (probably either byte
or uint64).

For large but fixed-size integers imposed by some other protocol (for
example mapping a protocol that has int128 into D-Bus), you could either
use a "bignum" encoding, or a struct (tuple) of type '(tt)' containing
(UINT64 high, UINT64 low).

> Another solution (but the most work) would be to add INT/UINT128 basic
> types. Is that within the realm of possibility?

Adding new types to the type system has practical interoperability issues
(the dbus-daemon has to decide whether to forward each message to each
recipient, each recipient has to announce whether it supports each type,
and high-level bindings like dbus-python have to cope somehow with
messages containing types that their lower-level library understands
but the binding does not), so there is a high bar to reach. I think UNIX_FD
was the only new type added since dbus 1.0 was declared stable, and it was
added to do something that was previously impossible, not merely awkward.

If we were going to add new types, the GVariant extensions (empty structs
and "maybe" types) seem a lot more compelling than new word-sizes
(INT128, UINT128, FLOAT), and the practical headaches involved in adding
the GVariant extensions have so far been enough that we haven't wanted to
add those either.

    S