[Python-bugs-list] [ python-Bugs-705836 ] struct.pack of floats in non-native endian order

[SourceForge.net]

Bugs item #705836, was opened at 2003-03-18 15:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705836&group_id=5470

>Category: Extension Modules
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Richard Hill (richardh2003)
Assigned to: Tim Peters (tim_one)
Summary: struct.pack of floats in non-native endian order

Initial Comment:
Python version 2.1 (2.2.1 behaves the same).
Windows 2000 and RH Linux 8.0

This was run on an Intel platform.

>>> v = 7.0 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 
+ .1
>>> v
7.9999999999999964
>>> struct.pack( "f", v )
'\x00\x00\x00A'
>>> struct.pack( ">f", v )
'@\x80\x00\x00'

These two should be the same byte pattern (only 
reversed)!

>>> struct.unpack( ">f", '@\x80\x00\x00' )
(4.0,)

!!!!!



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2003-03-20 13:48

Message:
Logged In: YES 
user_id=31435

Fixed.  In the 2.2 branch:

Lib/test/test_struct.py; new revision: 1.14.12.1
Misc/NEWS; new revision: 1.337.2.4.2.68
Modules/cPickle.c; new revision: 2.73.2.1.2.4
Modules/structmodule.c; new revision: 2.51.8.2

For 2.3:

Lib/test/test_struct.py; new revision: 1.17
Misc/NEWS; new revision: 1.700
Modules/cPickle.c; new revision: 2.141
Modules/structmodule.c; new revision: 2.58

----------------------------------------------------------------------

Comment By: Richard Hill (richardh2003)
Date: 2003-03-20 07:33

Message:
Logged In: YES 
user_id=737060

Thanks for getting back to me.

Your comment regarding IEEE formats is very interesting, I 
didn't know about this behaviour.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-03-20 00:25

Message:
Logged In: YES 
user_id=31435

Boosted priority because this is an especially bad kind of 
bug:  mysterious, subtle, and very rare ("most" in-range 
floats pack under "<f" and ">f" without problems; a problem 
requires that a carry out of the 25th most-significant-bit 
propagate thru a solid string of 24 1 bits).

For 2.2 I expect to check in a quick hack.  In 2.3 this code 
needs refactoring (structmodule and cPickle shouldn't have 
duplicated this delicate code)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-03-19 14:01

Message:
Logged In: YES 
user_id=31435

Yuck.  It's a bug in not accounting for that rounding can 
spill over the original bit width.  structmodule's pack_float() 
and pack_double() both have this flaw, although the one in 
pack_double() is much subtler.  A similar cut-and-paste 
bug is in cPicke's save_float().  I'll fix all this.

Note:  while "<f"'s result should be the byte-reversal 
of ">f"'s, there's no defined relationship between either of 
those and plain "f".  "f" is platform-native in all respects.  "<f" 
and ">f" force an IEEE-like encoding, even on non-IEEE 
platforms.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=705836&group_id=5470