Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!spdcc!m2c!ulowell!masscomp!alang
From: alang@masscomp.UUCP (Alan Groupe)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Turbo C file size routine
Message-ID: <2527@masscomp.UUCP>
Date: Sun, 8-Nov-87 21:23:46 EST
Article-I.D.: masscomp.2527
Posted: Sun Nov  8 21:23:46 1987
Date-Received: Wed, 11-Nov-87 04:25:16 EST
References: <2475@masscomp.UUCP> <32100013@bucc2> <1005@trotter.usma.edu>
Reply-To: alang@masscomp.UUCP (Alan Groupe)
Organization: MASSCOMP - Westford, Ma
Lines: 28


 bill@trotter.usma.edu (Bill Gunshannon) writes:
>
>Am I missing something here?   
>
>Why not just use filelength()?
>
>And of course if you find that too boring there is another method:
>
Yes Bill, I think you are missing something. Consider the following
small file:

a
b

What is the length of this file? Is it 6 bytes long (a<CR><LF>b<CR><LF>)
or is it 4 bytes long (a\nb\n)? The answer is: both. If the file is
opened in binary mode, you can read 6 characters from it. If it is
opened in text mode, you can read just four, as the TC runtime code
converts the <CR><LF> pair into a newline. I want to get back the 4,
but stat()/fstat()/filelength()/fseek()/ftell()/lseek() etc. will all
return 6, since they simply ask DOS for the file length. The original
posting asked if there were some manner of doing this other than simply
reading sequentially through the file. From the responses, it does not
appear that anyone was able to figure out any other way, although the
comment about doing larger reads is well taken.

Alan Groupe