Accounting changes

[Diomidis Spinellis]

Erik Trulsson wrote:
> 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

You're right - my mistake.  (I also tested this before posting 
(concidentally with 3.1415), but I botched when I converted the program 
I used for writing data on the SPARC into the program that read data on 
the i386 :-)

Diomidis Spinellis