Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!sun-barr!cs.utexas.edu!milano!lad-shrike!ut-emx!nather
From: nather@ut-emx.UUCP (Ed Nather)
Newsgroups: comp.lang.c
Subject: Re: binary data files
Message-ID: <12815@ut-emx.UUCP>
Date: 5 May 89 16:36:52 GMT
References: <10946@bloom-beacon.MIT.EDU> <225800167@uxe.cso.uiuc.edu>
Organization: The University of Texas at Austin, Austin, Texas
Lines: 25

In article <225800167@uxe.cso.uiuc.edu>, mcdonald@uxe.cso.uiuc.edu writes:
> 
> 
> >MS-DOS has exact filesizes in bytes, and a standard OS call to retrieve
> >a file's size in bytes.  The poster may have been thinking of CP/M,
> >but CP/M is not MS-DOS.
> 
> 
> Yes, but that size is the same as the number of characters returned
> by fgetc only if the file is binary. Not generally so if it is text.

Sorry, that's not correct.  The exact file size as it is present as an image on
the disk is indeed returned.  If, however, you read a file into memory in text
mode, its size will CHANGE due to removal of '\r' codes by the input routine.
You can avoid this behavior by referring to the text file as binary in the
'fopen' operation.  There are also C commands to set output to binary, if you
wish, so the '\r' codes are not inserted on output.

This whole mess came about because the author(s) of MS-DOS refused to accept
the Unix convention of a single '\n' newline character instead of '\r''\n'.
CPM still lives; its genes are hiding inside MS-DOS.

-- 
Ed Nather
Astronomy Dept, U of Texas @ Austin