Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!rutgers!bellcore!wind!tr From: tr@wind.bellcore.com (tom reingold) Newsgroups: comp.sys.ibm.pc Subject: Re: Turbo C file size routine Message-ID: <3576@bellcore.bellcore.com> Date: Mon, 16-Nov-87 08:32:44 EST Article-I.D.: bellcore.3576 Posted: Mon Nov 16 08:32:44 1987 Date-Received: Tue, 17-Nov-87 07:34:53 EST References: <2475@masscomp.UUCP> <32100013@bucc2> <1005@trotter.usma.edu> Sender: news@bellcore.bellcore.com Reply-To: tr@wind.UUCP (tom reingold) Organization: Bellcore, Morristown, Noo Joizy Lines: 27 Summary: Yes, you folks didn't read the posting. Please read this. In article <1005@trotter.usma.edu> bill@trotter.usma.edu (Bill Gunshannon) writes: $ [...] $ Am I missing something here? $ $ Why not just use filelength()? $ [...] Yes, you missed something because people have edited away the essential part of the poster's question. He wants to know what the file length would be if it were on a Unix system. That is to say, the CR/LF combinations on MS-DOS become only LF on Unix so the character count changes. Now, can you obtain the effective size of a file that way??? I don't think so. I think that his method, while (getc(fp) >= 0) char_count++; may in fact, be the only way. After all, how can you tell how many CR/LFs are in the file without reading them? Remember, most input routines in PC C compilers treat CR/LF's as a LF when the file is opened in text mode and thus the character count is different than the file size. Tom Reingold INTERNET: tr@bellcore.bellcore.com Bell Communications Research UUCP: !bellcore!tr 435 South St room 2L350 SOUNDNET: (201) 829-4622 [work] Morristown, NJ 07960 (201) 287-2345 [home]