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

[Mark Dickinson]

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 
consistently across platforms:

 - if the platform float format is unknown, the code turns a Python float into an 
IEEE-754 float anyway, and goes to great lengths to raise OverflowError when the 
Python float is too large to fit into an IEEE single-precision float.

 - if the platform float format is recognised as IEEE-754, then a C cast is used 
to turn the Python float (stored as a double) into a single-precision float;  for 
something that's too large for single precision, the natural result of that 
conversion is an IEEE-754 infinity.  I'm not 100% sure that the C standard (even 
C99) actually guarantees this, or whether there's a danger of floating-point 
exceptions being raised here.

I think the behaviour should be consistent:  either always raise OverflowError or 
always return the 4-byte sequence corresponding to an infinity.  I'm not sure 
which.  From the test-suite, it's clear that the original intention was that 
OverflowError should be raised.  On the other hand, 98.22% of Python users (i.e. 
those on IEEE-754 platforms) have been living happily with the 'output an 
infinity' behaviour for the last 5 years without noticing.  And we've been moving 
towards exposing infinities and NaNs more within Python.

One the OverflowError/infinity decision is made, this is a relatively easy fix, 
and I'd be happy to take care of it.

Christian, do you have any thoughts on this issue?

----------
nosy: +marketdickinson, tiran

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue705836>
____________________________________