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

[Udo Grabowski]

Hello,

The test code test.c given in
<https://www.illumos.org/issues/166>
also fails on gcc linux 4.1.2 20080704 x86_64 (centos 5.5), for 32
and 64 bit compilation float and double bytes ARE swapped from
XDR to little endian by gcc also:

Float test
	     Test value: 0x0052d2cc = 7.606130e-39
	    Encode test: FAILED
	       Expected: 0xfeedface 0x0052d2cc 0xfeedface 0xfeedface
	         Actual: 0xfeedface 0xccd25200 0xfeedface 0xfeedface
	    Decode test: FAILED
	       Expected: 0x0052d2cc = 7.606130e-39
	         Actual: 0xccd25200 = -1.102684e+08

So this is certainly the correct
behaviour, IEEE 754 representation independence does not imply
endian order in memory, otherwise endian-fixing standards like XDR
and network byte order wouldn't be necessary.

And it would not help to define a flag, since commercial software
is not source-code delivered, and I doubt that vendors would
compile two different versions for Solaris and Illumos. This
means that binary compatibility between Solaris and Illumos will
be broken for this case.

Jason King wrote:
> 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).

-- 
Dr.Udo Grabowski    Inst.f.Meteorology a.Climate Research IMK-ASF-SAT
www-imk.fzk.de/asf/sat/grabowski/ www.imk-asf.kit.edu/english/sat.php
KIT - Karlsruhe Institute of Technology            http://www.kit.edu
Postfach 3640,76021 Karlsruhe,Germany  T:(+49)721 608-26026 F:-926026