Would it be acceptable to use shorter float repr only on big-endian and 
little-endian IEEE 754 platforms, and use the full 17-digit repr on other 
platforms?  This would greatly simplify the adaptation and testing of 
Gay's code.

Notable platforms that would still have long repr under this scheme, in
order of decreasing significance:

  - IBM zSeries mainframes when using their hexadecimal FPU (recent
    models also have IEEE 754 floating-point, and Linux on zSeries
    uses that in preference to the hex floating-point).
  - ARM, Old ABI (uses a mixed-endian IEEE 754 format;  a newer set
    of ABIs appeared recently that use big or little-endian IEEE 754)
  - Cray SV1 (introduced 1998) and earlier Cray machines.  Gay's code
    doesn't support the Cray floating-point format anyway.  I believe
    that newer Crays (e.g., the X1, introduced in 2003) use IEEE
    floating-point.
  - VAX machines, using VAX D and G floating-point formats.  More recent
    Alpha machines support IEEE 754 floats as well.
  - many ancient machines with weird and wonderful floating-point
    schemes

As far as I can determine, apart from the IBM machines described above all 
new platforms nowadays use an IEEE 754 double format.  Sometimes IEEE 
arithmetic is only emulated in software;  often there are shortcuts taken 
with respect to NaNs and underflow, but in all cases the underlying format 
is still IEEE 754, so Gay's code should work.  Gay's careful to avoid 
problems with machines that flush underflow to zero, for example.

Gay's code only actually supports 3 floating-point formats: IEEE 754 (big 
and little-endian), IBM hex format and VAX D floating-point format.  There 
are actually (at least?) two variants of D floating-point:  the version 
used on VAX, which has a 56-bit mantissa and an 8-bit exponent, and the 
Alpha version, which only has a 53-bit mantissa (but still only an 8-bit 
exponent);  Gay's code only supports the former.

I'm quite convinced that the VAX stuff in Gay's code is not worth much to 
us, so really the only question is whether it's worth keeping the code to 
support IBM hexadecimal floating-point.  Given the difficulty of testing 
this code and the (significant but not overwhelming) extra complexity it 
adds, I'd like to remove it.