Big-endian double is incorrect

Bug #689433 reported by Phlip
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ghex (Ubuntu)

Bug Description

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
>>> struct.unpack('>d','\x12\x34\x56\x78\x9a\xbc\xde\xf0') # read as big-endian double - does not match ghex2
>>> struct.unpack('>d','\x9a\xbc\xde\xf0\x12\x34\x56\x78') # read as big-endian double with words swapped - matches ghex2

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

Revision history for this message
Phlip (q-launchpad-mrphlip-com) wrote :
Revision history for this message
inductiveload (inductiveload) wrote :

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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.