[Python-Dev] Re: marshal / unmarshal

Tim Peters tim.peters at gmail.com
Mon Apr 11 20:28:20 CEST 2005


...

[mwh]
> OK, so the worst that could happen here is that moving marshal data
> from one box to another could turn one sort of NaN into another?

Right.  Assuming source and destination boxes both use 754 format, and
the implementation adjusts endianess if necessary.

Heh.  I have a vague half-memory of _some_ box that stored the two
4-byte "words" in an IEEE double in one order, but the bytes within
each word in the opposite order.  It's always something ...

> This doesn't seem very bad.

Not bad at all:

    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.

>>>> Store a few small doubles at module initialization time and stare at

>>> ./configure time, surely?

>> Unsure.  Not all Python platforms _have_ "./configure time".
 
> But they all have pyconfig.h.

Yes, and then a platform porter has to understand what to
#define/#undefine, and why.  People doing cross-compilation may have
an especially confusing time of it.  Module initialization code "just
works", so I certainly understand why it doesn't appeal to the Unix
frame of mind <wink>.

>> Module initialization code is harder to screw up for that reason
>> (the code is in an obvious place then, self-contained, and doesn't
>> require any relevant knowledge of any platform porter unless/until
>> it breaks).

> Well, sure, but false negatives here are not a big deal here.

Sorry, unsure that "false negative" means here.

...

> Something along these lines:
>
> double x = 1.5;
> is_big_endian_ieee_double = sizeof(double) == 8 && \
>       memcmp((char*)&x, "\077\370\000\000\000\000\000\000", 8);

Right, it's that easy -- at least under MSVC and gcc.


More information about the Python-Dev mailing list