My patch is "convervative";
I believe the idea itself is endian-safe, and the patch as posted
it almost safe.  It does not assume a binary format, it checks; The line
if (b[0] == 0xc8b43958 && b[1] == 0x3ff3be76)
may need to be adjusted to include the check that it is a little-endian
machine (if floating point numbers are reversed on big-endian machines).  
I don't want to solve the problem for every machine to convert
between little and big endian.  I just want it to work on the most common
machine, the one I am using, and not break the others.  I am confident it
won't break the other platforms because they will set the floatingType
bits to FT_OTHER, which means that the 2 binary bytes at the end are
simply ignored, and so we are back to the original behavior.  I would like
to emphasize that I am not assuming any particular binary format for 
floating points, but instead testing at runtime what format is in use,
and only applying this fix if it happens to be the right one.  There is
still room for two other possible formats to be added, at least.  And
it is definately possible to cover the big-endian case as well without an
extra type code, but I would need access to a big-endian machine to test it.
The important point would be that the least significant floating-point
mantissa 8 bits are put in the first byte, then the next least significant
6 bits in the second byte.  This is endian-safe so long as you put them
back right, and are using IEEE754.