Floating-point and mixed-endianness in D-Bus (was: dbus mini-summit)

[Rémi Denis-Courmont]

Le lundi 8 août 2011 18:59:19 Simon McVittie, vous avez écrit :
> (Deliberately breaking the thread, this is only tangentially related)
> 
> On Mon, 08 Aug 2011 at 10:50:29 -0400, Colin Walters wrote:
> > * Talks of DBUS 2.0
> > 
> >   - What do we need to break
> >   
> >     - floats
> 
> This reminds me of something I'd been intending to bring up on this list.
> Recent discussion of multiarch on the debian-devel list brought up an
> interesting point: D-Bus' world-view is "there are only two native
> encodings, LE and BE", but the truth is more complicated, particularly
> for floating-point.

Most protocols either use:
- the native endianess and not support interchange,
- a network byte order and require a conversion for LE systems
(e.g. IETF protocols),
- little endianess (e.g. USB and many Intel and Microsoft protocols).

I understand the motivation to use the native endianess if possible. But in 
practice, I think it would be faster to just use a fixed endianess and convert 
on the fly in the D-Bus implementations. In practice, systematic (selected at 
build-time) conversion is probably faster than conditional (selected at run-
time), if only because a byte swap is faster than a conditional branch.
It's also simpler at the source code level.

An alternative is to give-up on D-Bus over the network.

> (0) char has 8 bits
>     C standards explicitly do not require this, to allow for oddities like
>     36-bit words with 9-bit bytes (PDP-10). I don't think we really care...

Yeah. But if uint8_t and int8_t are defined by <stdint.h>, then char is 8-
bits, and...

> (1) Every useful ABI encodes negative integers in "two's complement",
>     like x86 does
>     C standards explicitly do not require this - they allow sign-and-
>     magnitude too - but I'm not aware of any useful CPU where it isn't true.

...two complement is used (by definition of intN_t types), and...

> (2) Every useful ABI has 8-, 16- and 32-bit integers, and optionally also
>     64-bit integers.

...short, int, long and long long will be multiple of 8-bits in width, thus 
effectively, 16, 32 will be available and 64 most certainly.


I would just leave it upon the two remaining users of PDP computers to write 
their own interoperable implementation of D-Bus without those assumptions. 
Presumably, they have a way to interchange octet-aligned data. Otherwise they 
cannot connect to the Internet and are irrelevant.

> (4) Native integers are all in the same byte-order
>     I believe it's also valid (although ill-advised) for a platform to have
>     big-endian 16-bit integers but little-endian 32-bit. I don't propose to
>     pretend we support such platforms.

This wouldn't be a problem if D-Bus had a fixed endianess on the wire.

-- 
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis