Re: Read binary data file
~kurt wrote:
Martin Gregorie <martin@see.sig.for.address> wrote:
If the OP *MUST* move binary data, at least do it in a platform and
language-independent manner and use ASN.1 encoding.
I understand Hunter's comments, and and while I don't know much about
ASN.1 encoding, what I am pointing out is that binary files are usually
*not* intended to be used across sytems. Every binary data file I have
ever worked with was intended to be used either by the program that wrote
it, or separate applications that used the same utility libraries as the
application which wrote the data.
Pretty much all scientific data I have worked with over the past 25 years has
been written in binary, and is intended to be read on just about any platform
you'd care to use. The basic principle behind being able to do this is writing
the binary data in a well structured form, in a reliable and portable way.
There is nothing wrong with simply writing
the C structure to a file, and reading it in the same way.
There is everything wrong with this. This is the fundamental problem. The amount
of padding which is used internally within a struct is undefined by the
language - it is entirely up to the compiler developer. If you write a struct
in binary both the data *and the padding* will be output together, all
intermingled. Further, since the amount of padding is at the discretion of the
compiler writers they are free to change the amount they use in any release of
their compiler. So you could quite easily find that an upgrade to the compiler
causes your code, which you say is perfectly acceptable, to break even on the
same hardware and OS.
In this case
the code, and not some specification, drives the format of the data - and
there
is *nothing* wrong with this.
Yes there is. Code which writes unspecified data to a binary file is bad code.
It will almost certainly break at some time in the future.
The lack of a need to share the data outside of
the application is what often drives the decision to use binary data in the
first place (why not take advantage of the efficiency binary files have to
offer).
But it is wise to know what is being written into your binary file so that you
can reliably read it back in. Otherwise it's reverse GIGO, it's GOGI - garbage
out, garbage in.
Of course, every once in a while an outside user decides they want to use this
data. Well, then they have a choice. Either generate it themselves, or
spend a few hours writing something that can read it in - not a big price
to pay.
But somewhat difficult if the original program's author didn't know what they
were writing into their binary files. I
--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : nmw@ion.le.ac.uk
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555