[Python-Dev] Re: marshal (original) (raw)

[Python-Dev] Re: marshal / unmarshal

Tim Peters tim.peters at gmail.com
Mon Apr 11 00:37:44 CEST 2005

[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.

More information about the Python-Dev mailing list