Mail Archives: djgpp/2004/12/25/11:39:50
I think you need to rethink your expectations.
When you read binary data in from a file, it gets copied into memory
exactly as it comes from the file. Thus, if you want to store a
binary integer in a binary file, you need to *write* a binary integer
into the file. If you write an array of char, you should read an
array of char. If you write an array of char yet read a binary
integer, the bytes you read will be interpreted according to the new
type.
The read functions will NOT convert types for you. To do that, you
should use the various type conversions, like ntohl or sscanf, or read
an array of chars and build the types manually using arithmetic.
Note that if you have a bytestream 12 34 56 78, and map it onto an
integer, I'd expect you to get 0x78563412 because integers on i386 are
little endian. If you write an i386 integer and read that file on an
SGI, you'd get the bytes swapped again, because SGIs are big endian.
Relying on the host integer format to be portable is BAD programming.
In short, if you want a binary valud 0x12345678 read from the file,
you need to store bytes 78 56 34 12 into it, because that is the
integer format for i386. But what you really should be doing is not
assuming anything about integer layout at all. It is not Intel's
expectations that are corrupting you, it is your own.
- Raw text -