[Python-Dev] Re: marshal / unmarshal

[Tim Peters]

[mwh]
> OTOH, the implementation has this comment:
>
> /*----------------------------------------------------------------------------
> * _PyFloat_{Pack,Unpack}{4,8}.  See floatobject.h.
> *
> * TODO:  On platforms that use the standard IEEE-754 single and double
> * formats natively, these routines could simply copy the bytes.
> */
> 
> Doing that would fix these problems, surely?[1]

The 754 standard doesn't say anything about how the difference between
signaling and quiet NaNs is represented.  So it's possible that a qNaN
on one box would "look like" an sNaN on a different box, and vice
versa.  But since most people run with all FPU traps disabled, and
Python doesn't expose a way to read the FPU status flags, they
couldn't tell the difference.

Copying bytes works perfectly for all other cases (signed zeroes,
non-zero finites, infinities), because their representations are
wholly defined, although it's possible that a subnormal on one box
will be treated like a zero (with the same sign) on a
partially-conforming box.

> [1] I'm slighyly worried about oddball systems that do insane things
>    with the FPU by default -- but don't think the mooted change would
>    make things any worse.

Sorry, don't know what that means.

> The question, of course, is how to tell.

Store a few small doubles at module initialization time and stare at
their bits.  That's enough to settle whether a 754 format is in use,
and, if it is, whether it's big-endian or little-endian.

...

> [2] Exaggeration, I realize -- but how many non 754 systems are out
>    there?  How many will see Python 2.5?

No idea here.  The existing pack routines strive to do a good job of
_creating_ an IEEE-754-format representation regardless of platform
representation.  I assume that code would still be present, so
"oddball" platforms would be left no worse off than they are now.