[issue705836] struct.pack of floats in non-native endian order

Mark Dickinson <[EMAIL PROTECTED]> added the comment: Fixed in r61383. -- status: open -> closed Tracker <[EMAIL PROTECTED]> ___ Pyt

[issue705836] struct.pack of floats in non-native endian order

Mark Dickinson added the comment: Coming back to this, I think that it actually *is* clear what struct(">f", large_float) should do: it should raise OverflowError. This fits in well with the general philosophy that Python (at least tries to) follow for floating-point exceptions. The attached pa

[issue705836] struct.pack of floats in non-native endian order

Mark Dickinson added the comment: I'm stealing this issue from Tim, and downgrading the priority to normal (it was the original bug that was high priority). -- assignee: tim_one -> marketdickinson priority: high -> normal versions: +Python 2.6, Python 3.0 __

[issue705836] struct.pack of floats in non-native endian order

Christian Heimes added the comment: Sounds like a good idea to me. Although all major platforms support IEEE Python should guarantee a stable behavior on all platforms. The lines should be a safe replacement of the downcast: double fromd; float tof; tof = abs(fromd) >= FLT_MAX ? FLT_MAX : fromd;

[issue705836] struct.pack of floats in non-native endian order

Mark Dickinson added the comment: Here's a patch that fixes the test that Collin mentioned to reflect what's actually been happening for the last nearly 5 years, and changes _PyFloat_Pack4 and _PyFloat_Pack8, as follows. When packing a float that's too large for the destination format (e.g.

[issue705836] struct.pack of floats in non-native endian order

Mark Dickinson added the comment: Aha: the C99 standard, section 6.3.1.5, says: When a double is demoted to float, a long double is demoted to double or float, or a value being represented in greater precision and range than required by its semantic type (see 6.3.1.8) is explicitly converted

[issue705836] struct.pack of floats in non-native endian order

Mark Dickinson added the comment: It's a little odd: the relevant code is in floatobject.c, in _PyFloat_Pack4. The issue is what happens when a Python float (stored internally as a platform double) is packed as an IEEE-754 single-precision float. The current code doesn't behave consistent

[issue705836] struct.pack of floats in non-native endian order

Facundo Batista added the comment: A lot of water passed around this bridge, but I don't know if this is fixed: In the trunk right, now: >>> v = 7.0 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 + .1 >>> v 7.9964 >>> p = struct.pack( ">f", v ) >>> p 'A\x00\x00\x00' >>> struct.unpack(