Mark Dickinson <dicki...@gmail.com> added the comment: I think my -1 for adding the new format was premature: I was hoping to find a way to fix marshal for the 'unknown' format, but the cleanest solution does indeed appear to be to add the mixed-endian format. And apart from the Python/compile.c oddity I can't find anywhere besides Objects/floatobject.c that needs to be changed, so the patch only has to touch one file.
Here's a reworked version of Aurelien Jarno's patch, against the trunk. The key differences, from more significant to less, are as follows: - I've abstracted out the 3 different byte orders, so that the same code does the packing and unpacking for all 3 different formats. I think things should be safer and more maintainable this way (and it makes life easier when some other wacky byteorder comes along). - Rename the format to "IEEE, ARM mixed-endian". Note that these mixed- endian doubles are perfectly valid IEEE 754 doubles, so the name should start with "IEEE" so that the various IEEE 754-specific tests are enabled on ARM. The IEEE 754 standard has precisely nothing to say about endianness or serialization of floats as byte sequences: the words 'endian', 'byte' and 'octet' don't even appear anywhere in the standard. - In float.__setformat__, don't allow setting of "IEEE, ARM mixed-endian" for the 'float' type, only for the 'double' type. (If I understand correctly, when the double type is ARM mixed-endian the float type will always be little-endian; there are no mixed-endian single-precision floats to worry about.) - whitespace cleanups, expanded comments and docstrings, and line length fixes. I've tested this on two versions of OS X: 10.5.6/Intel (little-endian), and 10.4.10/PPC (big-endian), with no (new) test failures. I fully expect that this patch will cause test failures on ARM as a result of the IEEE tests being enabled, but that's better than a build failure. If there's someone who's willing to provide feedback I'll work to fix those test failures. I'm still not sure whether this can be a candidate 2.6 and 3.0. Martin, do you have any thoughts on this? To Mark Miller and Aurelien Jarno: is either of you in a position to test this patch on the relevant mixed-endian platforms? ---------- stage: -> patch review versions: +Python 3.0, Python 3.1 -Python 2.5 Added file: http://bugs.python.org/file13076/arm-float2.diff _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1762561> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
