Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!decwrl!shelby!csli!poser
From: poser@csli.Stanford.EDU (Bill Poser)
Newsgroups: comp.lang.c
Subject: Re: binary data files
Message-ID: <8815@csli.Stanford.EDU>
Date: 4 May 89 07:33:50 GMT
References: <10946@bloom-beacon.MIT.EDU> <12546@ut-emx.UUCP> <8758@csli.Stanford.EDU> <11021@bloom-beacon.MIT.EDU> <14301@bfmny0.UUCP>
Sender: poser@csli.Stanford.EDU (Bill Poser)
Reply-To: poser@csli.stanford.edu (Bill Poser)
Organization: Center for the Study of Language and Information, Stanford U.
Lines: 15


It is true that some operating systems don't allow you to determine the
true file size, but essentially any program that does file i/o,
graphics, or other dealings with the outside world has to make some
assumptions about the OS. After all, some OSs don't provide for
shared memory or execution of child processes or our favorite
graphics system or window system. And some really grody
operating systems have zillions of file types, which generally do not
have exact counterparts in other OSs, so just using text
files (I don't write "ASCII" since some of the nasty OSs in question use
EBCDIC) doesn't make the program portable. For many of us (admittedly
not all) the class of UN*X systems is a large enough target for
portability. And if, as I do, you are dealing with files containing
millions of numbers, the efficiency of using binary data can be a big
win.