Accounting changes

[Erik Trulsson]

On Sun, May 06, 2007 at 02:43:54PM +0300, Diomidis Spinellis wrote:
> Peter Jeremy wrote:
> >On 2007-May-06 12:06:02 +0300, Diomidis Spinellis <dds at aueb.gr> wrote:
> >>Garance A Drosehn wrote:
> >>>Does this mean the new accounting record will be using the
> >>>native-hardware format for floating point numbers?  Does that mean
> >>>the records produced will be different for different hardware?
> >>My intention is to use the standard (IEEE 754-1985 / IEEE 854-1987 / IEC 
> >>60559) 32-bit float format.  This is the C "float" type on all the 
> >>architectures we support.  I could add a typedef clarifying this, but I 
> >>doubt we'll ever support an architecture (VAX?) where float is a 
> >>different format.
> >
> >IEEE-754 etc define how to interpret a 32-bit object as a floating
> >point number.  AFAIK, it does not define how that object is laid
> >out in memory so that a float written on SPARC (big-endian) will
> >be different to that written on an i386 (little-endian).
> 
> IEEE-754 defines the order of bits in a number.  The intention is to 
> allow lexicographical comparison of (valid) floating point numbers, 
> using the normal byte compare instructions.

Not quite. They are defined in such a manner as to allow them to be
lexicographically compared just as if they were integers.  And just like
integers the byte order can vary between different architectures.


>  If you write a file with a 
> float on a SPARC you can read it back correctly on an i386.

No you can't.  I just tested this to be certain.
On a SPARC a 32-bit float with the value 3.14 is stored as the bytes (in 
hexadecimal notation):
  40 48 f5 c3

On i386 the order is
  c3 f5 48 40




-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013 at student.uu.se