Re: Structure size and binary format


(Please excuse the vacuous reply that I fat-fingered
a moment ago.)

Chuck F. wrote:

gamehack wrote:


I've been wondering when I write a structure like:

struct {
  int          a;
  unsigned int b;
  float        c;
} mystruct;

And then I'm using this as a record for a binary file. The
problem is that the size of the types is different on different platforms(win/lin/osx) so if a file was copied on another
platform and attempted to be read then the first say 16 bytes
could be regarded as the integer a but it could have been
created on system where integer was 32 bytes.


Good. You recognize the existence of a problem. The answer is "Don't do that". Binary representations are, in general, not portable. You can convert things into a sequence of bytes and write/read those to a file, but that means you also have to write the conversion mechanisms. Now such things as byte sex can bite you. 

    "Don't do that" needs a little qualification, I think.
If "that" means "just read and write the struct in whatever
form the compiler happens to choose," the advice is sound.
But the claim that binary representations are not portable
(I'm not sure what "in general" means here) doesn't hold up.
Who has not transported a ZIP or GIF or JPEG file between
dissimilar systems?  At a lower level, who has not exchanged
IP packets with other systems?  Portability is a matter of
agreed-upon standards, not of the underlying representations
chosen.

Far and away the most portable transportation mechanism is pure text. You already have conversion routines in the standard library, and all you need to do is use them. Anybody and their dog can read the files. 

    Text has a few pitfalls of its own.  Even without appealing
to the multitude of character encoding schemes, some difficulties
are apparent.  For example, it is no simple matter to devise a
portable text representation for arbitrary `double' values.  A
value encoded as text, sent to another machine and decoded, then
re-encoded and sent back again may not decode to the same value
that was originally transmitted.  It requires as much care to
make this work for text as for binary representations.  (And I've
got the war stories from a PPOE to prove it, too ...)

--
Eric Sosman
esosman@xxxxxxxxxxxxxxxxxxx

.

Relevant Pages

  • Re: NULL and zeros
    ... I assume the target platform can run X ... *hypothetical* portability more important than convenience in my ... If you want to initialize a struct without knowing what elements ...
    (comp.lang.c)
  • Re: How can I obtain 2 and 4-byte data types?
    ... > Yesterday I found a portability issue I can't seem to get around and ... all my code falls to pieces if there is no data type ... > and still write it in big and little endian?? ... insert padding bytes after any element of a struct (including ...
    (comp.unix.programmer)
  • Re: When shorts are longer than longs !
    ... application where a union of different bitfielded ... In my professional life, portability is of concern, as the program I maintain has, over the years, had to run on many platforms, including MS-DOS, VMS, too-numerous-to-remember varieties of Unix, Linux, etc. etc. etc., as well as big- and little-endian systems. ... Many years ago we had a struct for flags, ... Does ISO C now specify how bitfields are allocated within the data? ...
    (comp.lang.c)
  • Typecasting portability in C
    ... What I am trying to do is implement polymorphism in C. ... void* but then typecast it and get the signature out of the object. ... struct SomeObjectType { ... again what about portability. ...
    (comp.lang.c)
  • Re: Structure size directives
    ... It not portable in C. Ada is totally different. ... Ada makes structure packing portable by picking one strategy and insisting ... obstacle to portability, or you might call it a sensible unwillingness to ... the various struct packing strategies are not a serious ...
    (comp.lang.c)