illumos gate

There are more lines to fix here:
Lines 71,112,122,123,197,198,201,289,329,229,349,424,434,517.
Question: are __mc68000, __u3b2, __u3b15 and __vax are still supported
targets ? If not, these definitions can be just eliminated.

Found Fasttrack PSARC/2010/211 <http://www.mail-archive.com/opensolaris-arc@opensolaris.org/msg00968.html>
which has been approved, so __mc68000, __vax, __u3b2 and __u3b15 are
no longer supported.

There might be better symbols available to determine which is the native float format, etc.
Have a look at sys/isa_defs.h and _IEEE_754, for example.

Many cases in xdr_float.c should be able to say basically:

#ifdef _IEEE_754
    /*
     * OtW format is IEEE so just copy.  Includes CPUs:
     * amd64, i386, sparc, sparcv9, m68k, u3b2, etc.
     */
    return (XDR_PUTINT32(XDRS, (int *)fp));  /* or whatever... */
#else
    /* vax and whatever - do we care anymore? */
#endif

Regardless, the function could be cleaned up.

http://cr.illumos.org/view/krrvaz21/ has a proposed cleanup.

It seems that this issue may not be fixed. I tested the test.c program
on 134b (unfixed), and it fails as expected, and then tested on
Osol 2009-SU7 (amd64) with the IDR35 fix delivered by Sun that gives
the correct representation (that is, IDL works correctly). But the
test.c program still completely fails on the fixed platform. This
means that the test program must be wrong, and so the fix is probably
also wrong.

To my understanding the XDR format is always big_endian, and the
xdr_float.c should convert this to little_endian on import from a
XDR file (or stream/socket), or to big_endian when exporting to a
XDR file on little_endian platforms only.

Since IDL treats XDR the same on all platforms, a working IDL is a hint for
a correct implementation, which means that IDR35 delivered a correct fix,
with which the test program should work on OSOL 2009.06 + IDR35.
So the fix should follow what the original code did with the correct compiler
definitions (__amd64 instead of amd64 etc.)

Please provide the output of the test program. It should generate identical XDR byte streams on x86, amd64, sparc, and sparcv9 (I verified this before putback).

I strongly suspect the IDR is wrong. Integer values are encoded big-endian, thus need to be byteswapped when read in on x86 platforms. However floating point values are stored using the IEEE 754 representation (this is straight from RFC 1831). IEEE 754 which uses the same byte order on all platforms. There is no conversion required. The suggested fix in the Sun ticket is plain wrong (and probably has been wrong for as long as Solaris has supported x86 -- it's been verified as far back as Solaris 9, but couldn't find any older machines). The suggested fix will byteswap floating point values (which is incorrect).

You might also want to contact the vendor of the software --- I have a feeling it's been compensating for this error on x86 for a while (it would be good to confirm that).
The loss of the #ifdef made the code fall through to the platform-independent code which should convert close to the actual value, so was less ideal but mostly correct.

It is essential that the actual raw hex values be examined of the resulting XDR stream (as well as the original values) to understand the transformation.

Of course, it swaps:
Double test
Test value: 0x60217895 0x775db1e2 = 9.574971e+266
Encode test: FAILED
Expected: 0xfeedface 0x60217895 0x775db1e2 0xfeedface
Actual: 0xfeedface 0xe2b15d77 0x95782160 0xfeedface
Decode test: FAILED
Expected: 0x60217895 0x775db1e2 = 9.574971e+266
Actual: 0xe2b15d77 0x95782160 = -3.006403e-205

Interestingly, the test.c works on sparc 5.10 (which is the fixed standard Solaris XDR code !)

I don't know where you got the information that IEEE754 representation MUST be BE on
all platforms, I think this assumption is simply wrong (and would be totally inefficient for
x86/x64), Wikipedia says this:

From en.wikipedia.org/wiki/Endianness
Floating-point and endianness

On some machines, while integers are represented in little-endian form, floating point numbers are represented in big-endian form.[3] Because there are many floating point formats, and because there is an absence of a "network" standard representation for them, no endianness standard for transferring floating point values between heterogeneous systems has become universally accepted. This means that floating point data written on one machine may not be readable on another, and this is the case even if both use IEEE 754 floating point arithmetic since the endianness of the memory representation is not part of the IEEE specification.[4] ^^{^^}^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^{^^}^^^^^^^^