[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: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
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-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