... [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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com