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

[Jason King]

Not a big deal.. one of the downsides of online communication is
sometimes things don't always come through that might in person..

I'm tempted to just drop the code completely.  Are there any platforms
in widespread use today that don't use IEEE 754?  The code suggests
that as far back as 1985, vax was the only one that didn't.  If there
is, my guess is that there's probably going to be code specific for
that platform that's going to be more accurate and faster to translate
anyway.

Outside of that, we are trying to track down an interesting issue (but
could be our relative lack of knowledge about fp implementations on
the processor, so we're still researching).   It doesn't appear to be
caused by this issue (but should probably be resolved at the same
time) relating to the representation of +NaN vs. -NaN on sparc & x86.
Part of it is it's not clear how to correctly assign +NaN or -NaN (if
even possibly) to a float or double to verify that what gets written
out is correct for those two values (+/- INFINITY as well as other
values now are correct across platforms).

On Sun, Jan 30, 2011 at 7:58 PM, Gordon Ross <gordon.w.ross at gmail.com> wrote:
> On Sun, Jan 30, 2011 at 7:26 PM, Garrett D'Amore <garrett at nexenta.com> wrote:
>> Has everyone who raised feedback on your last change had a chance to
>> review and comment on these updates?
>
> My suggestion about using #pragma redefine_extname was  made in a chat
> discussion about how one could make both the portable and IEEE
> versions of the library available to a test program.  I have mixed
> feelings about including both versions of the code in a production
> build of the library.  Further, if we don't try to do that, I think we
> could skip the xdr.h changes entirely.
>
> Maybe a better way to make both the portable and IEEE code testable
> would be to introduce a "test" compile (somewhere) that builds this
> code with a special pre-processor symbol like USE_PORTABLE_CODE, and
> let that cpp symbol cause both variants to build for module test
> program use.
> Other ideas welcome.  I do like code that has module tests.
>
> Sorry if I've lead you astray, Jason.
>
> Gordon
>