[illumos-Developer] Ugh... xdr_{float,double} problems

[Jason King]

After lengthy discussions, and even more digging... it looks like
there's a bit of a very-long standing mess with the C xdr API.

The problem is, the OTW XDR format for 32 & 64 bit doubles is
identical on x86, amd64, sparc, and sparcv9.  In theory, the code
should then just merely copy the values out unchanged.
However, that really happened was on little-endian platforms, the byte
values for fp values were being (incorrectly) byteswapped by the
library.  Instead of fixing the library, it appears the existing
software that actually uses fp with xdr workaround the bug on those
platforms.  Of course the recent putback broke the workaround.

Essentially:

1. code is released with broken xdr_{float,double}
2. code is written w/ workarounds
3. code is updated, and __amd64 define is (incorrectly) changed to
amd64.  This causes xdr_{float,double} to revert to a slower, platform
independent version that correctly (minus rouding errors) writes the
value into the stream (without swapping).
4. My fix correctly writes fp values unchanged to XDR stream, but also
breaks any software with workarounds.  The test cases were written to
the RFC & man pages (since I couldn't really find anything out there
that uses

Given the pervasiveness of this, we probably need to do something similar to:

1. Revert the behavior to the traditional broken behavior
2. Update the man pages to document this behavior
3. Add a #define to the rpc/xdr.h header file (XDR_FLOAT_NO_SWAP ?) to
allow applications to select the correct behavior when defined (and
document this in the manpage).