Re: portable issue of storing float point value in file

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Almon B. Strowger (strowger_at_NOSPAM.kook.com)
Date: 05/14/04 

Date: Fri, 14 May 2004 00:54:44 -0700

Hi,

    What other people are you talking about?
If you mean other users of your application:
  My solution does deal with it because it is based
  on whatever the *file specification* dictates.
If you mean the general public--as to the broader
 concepts relating to such issues:
  Same answer.

There is always more than one way to "skin a cat."
Of course you can read it in that way and correct
the endianness if it is so required. You can also
load it into blocks of memory and use _swab() to
swap, or swap as you read, etc. The solution I
proposed works no matter what the endianness
of any machine is. Because the endianness of
the number in the data file is whichever way you
define it in the *file specification* no matter what
platform or architecture you're running on.
It doesn't matter if it's an old 8-bit machine or some
new-fangled 128-bit machine--They will all be able
to serially read a byte stream from mass storage
consistently and without confusion.

I've been trying to be clear here, and I'm sorry if I
haven't been explaining it well enough.
At this point, I don't know how else I could
explain it any better.

Hope this helps...

Almon B. Strowger
KOOK Pocket Software

"Kenji Chan" <no@no.com> wrote in message news:40a3ddfb@dnews.tpgi.com.au...
> I know what u mean, u just "bitwise or "join" each byte together again
> whenever u read/write the value
>
> yes, your idea is good, but other people still need to deal with endian
> issue
> within the same code, it seems like no-problem
>
>
> > to. And then, as andrew stated, when reading the data from
> > the file, you do it a byte at a time and reconstruct the integers
> > with something such as:
>
>
> no, actually we can read the whole 4-bytes (if long),
> and then use correct_endian marco (see below)
> (and your method should be little endian too)
>
> #ifdef big_endian
> #define correct_endian(x) (convert_to_little_endian(x))
> #else
> #define correct_endian(x) (x)
> #endif
>
>
>
> > Why create a problem for yourself by doing a
> > memory dump?!
> > I have a feeling that you don't quite understand completely what
> > we've been telling you.
> > Here's what I understand you are doing at this point:
> >
> > You now store Lat. & Long. in integer types and you need to
> > write them to a file that keeps data in a format that is consistent
> > from machine to machine and you are trying to write an application
> > that can be compiled to platforms of differing endianness without
> > any problems using the same data file for any machine.
> >
> > So--Instead of steaming through memory and dumping an image
> > to the file (which would create the endianness problem.)
> > You do what I stated before--I will paste it in again:
> >
> > DWORD fooData = 0xCAFEBABE;
> > BYTE a,b,c,d;
> > a = HIBYTE( HIWORD(fooData) );
> > b = LOBYTE( HIWORD(fooData) );
> > c = HIBYTE( LOWORD(fooData) );
> > d = LOBYTE( LOWORD(fooData) );
> >
> > I'll try to explain it in more detail this time.
> > Imagine that fooData is one of your integers, say, a latitude.
> > What you do is break it up into bytes, and as per the
> > file format specification that you define, you write the bytes to
> > the file as bytes--not DWORDs. Maybe the HIBYTE and
> > LOBYTE macros confused you--They have NOTHING to
> > do with a higher or lower memory address--They have to do
> > with the higher or lower order bits of the represented integer.
> > Therefore, it doesn't matter how the integer is represented
> > in memory. So you take advantage of letting the compiler
> > deal with the endianness under the hood, so you don't have
> > to. And then, as andrew stated, when reading the data from
> > the file, you do it a byte at a time and reconstruct the integers
> > with something such as:
> >
> > BYTE a, b, c, d;
> >
> > // Read the bytes from the file here...
> >
> > DWORD bazData = MAKELONG( MAKEWORD( d, c ),
> > MAKEWORD( b, a ) );
> >
> > Hope this helps...
> >
> > Almon B. Strowger
> > KOOK Pocket Software
> >
> > "Kenji Chan" <no@no.com> wrote in message
> news:40a34641@dnews.tpgi.com.au...
> > > yes, it is a "memory dump" u can say
> > >
> > > > standard format, then the endianness issue has already been dealt
> with.
> > > > If this is a newly defined file format--Which it clearly seems to
> > > be--There
> > > > really is no issue here because unless a memory dump or a predefined
> > > > file or data transfer format is being used, the endianness problem
> need
> > > > not be a problem at all. No matter what the endianness of a machine
> > >
> > > no, e.g. a short like CD FF(hex) or 52735(dec)
> > > in one machine writes CD FF (big-endian)
> > > the other could write FF CD (little-endian) <-- most PCs
> > >
> > > > is, any machine can take a raw file and know the serial order of the
> > > > bytes that are read in. So just break the number into bytes and
even
> > > > invent your own "endianness" for the file format if you want, eg.
> > >

Relevant Pages

  • Re: Byte ordering and array access
    ... split) in the context of endianness? ... implementation specific representation. ... computer memory was stored in little magnetic ... and re-assembling, and it always cooperates with itself. ...
    (comp.lang.c)
  • Re: Endianess
    ... > processor and the way it stores data in the memory subsystem. ... Endianness is a not so much a property of memory or CPU or I/O but of the ...
    (comp.sys.arm)
  • Re: Innovative Systems FPE...
    ... you'd handle endianness translation in hardware ... ... I was considering that they may have mapped the register ... ;-) If one is prepared to visualise memory addresses bassackwards I ...
    (comp.sys.apple2)
  • Re: portable issue of storing float point value in file
    ... write them to a file that keeps data in a format that is consistent ... that can be compiled to platforms of differing endianness without ... So--Instead of steaming through memory and dumping an image ... >> file or data transfer format is being used, the endianness problem need ...
    (microsoft.public.pocketpc.developer)
  • Re: Backwards File Dump
    ... always display the least significant on the right no matter what the ... > presents to the programmer a big endian view of memory, ... > utility should not try to shelter you from the endianness and your present you ... > So what this means is that the VAX format doesn't really help for binary, ...
    (comp.os.vms)