Big-endian double is incorrect

[Phlip]

Binary package hint: ghex

In big-endian mode, the calculation of the "64-bit float" display is broken, and actually calculates it using a middle-endian order... the 8 bytes are broken into two 4-byte words, and each word is read big-endian as requested, but the two words are then combined in a little-endian order.
In little-endian mode, the display is correct.

If the file reads 12 34 56 78 9A BC DE F0, for example, and you get it to read it as a double in little-endian format, then it correctly says "-4.886460e+235", which is the value that would be represented in a double as 0xF0DEBC9A78563412, ie that file correctly read in little-endian format.
However, reading that same file as big-endian, it should show 5.626349e-221, being the double represented by 0x123456789ABCDEF0... but instead it shows -6.957644e-180, which is the double represented by 0x9ABCDEF012345678, a middle-endian scrambling of the input value.

For comparison, Python:
>>> struct.unpack('<d','\x12\x34\x56\x78\x9a\xbc\xde\xf0') # read as little-endian double - matches ghex2
(-4.8864596550437747e+235,)
>>> struct.unpack('>d','\x12\x34\x56\x78\x9a\xbc\xde\xf0') # read as big-endian double - does not match ghex2
(5.626349274901198e-221,)
>>> struct.unpack('>d','\x9a\xbc\xde\xf0\x12\x34\x56\x78') # read as big-endian double with words swapped - matches ghex2
(-6.9576436610961059e-180,)

This is with ghex package version 2.24.0-1, on Lucid 10.04.1 amd64.

[inductiveload (inductiveload)]

Looks to be fixed at some point between 2010 and v. 3.6.0.

Big-endian display of "12 34 56 78 9A BC DE F0" is correctly interpreted as 5.626349e-221.