Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!adam.pika.mit.edu!scs
From: scs@adam.pika.mit.edu (Steve Summit)
Newsgroups: comp.lang.c
Subject: binary data files
Summary: more reasons not to
Message-ID: <10946@bloom-beacon.MIT.EDU>
Date: 29 Apr 89 06:15:55 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: scs@adam.pika.mit.edu (Steve Summit)
Lines: 33

From time to time we debate the relative merits of "binary" and
"ascii" data file formats.  Today I discovered Yet Another Good
Reason not to use binary files, a fact which I was in general
already eminently certain of.  I'll pass the reason on, in case
it will keep anyone else from making the same mistake.

I am working with some code which, for historical reasons, writes
C structures out to files and reads them back in, in the usual
(unrecommended) byte-for-byte binary way, using fwrite and fread.
It happens that the structures contain pointers, the writing of
which to files is an even worse idea, because the pointers are
virtually certain to be meaningless when read back in.  The
struct-writing code is therefore careful to chase down the
pointers and additionally write the substructures and strings
pointed to; the struct-reading code ignores the garbage pointers
read in and replaces them with new pointers to the memory
containing the pointed-to information just read from the file.

This is all well and good, and has been working just fine, but it
happens that it is on the benighted PC, and today I thought I'd
switch from medium model to large model.  Surprise, surprise,
those 16-bit garbage pointers I wrote out yesterday are now
trying to be read in as 32-bit garbage pointers, offsetting the
rest of the data, and several thousand data files are currently
unreadable...

(You don't need to chide me for using binary files in the first
place, a fact for which I am amply chiding myself already, or
suggest ways out of the dilemma, any number of variously
unpalatable ones of which I am already considering.)

                                            Steve Summit
                                            scs@adam.pika.mit.edu