Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Working with files on different operating systems Date: Fri, 09 Oct 2015 16:57:53 -0700 Organization: None to speak of Lines: 40 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="2062"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+8/iY4QFFHsEYDeuwWKK/n" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:dgdEUfJIWqlSJr5SP4kJ6Xsf+b4= sha1:Kdpqmslxoalig+5R3sFqL0BCS60= Xref: csiph.com comp.lang.c:72355 Les Cargill writes: > Keith Thompson wrote: [Snipping stuff where we pretty much agree] >> The value returned by ftell() is not guaranteed >> to be meaningful, and neither fseek() nor ftell() is guaranteed to >> work at all on all files. On Windows, the size of a file generally >> does not match the number of characters that can be read from it >> in text mode. > > This is an excellent reason not to use text mode. Text mode also > can be related to, or ( on the right platforms ) may even use directly > "cooked mode" from the old BIOS calls, and that's just wrong :) Rather, I'd say it's an excellent reason not to assume that I can predict exactly how many bytes I'll be able to read from a file in text mode. I'd rather use text mode than deal with the vagaries of "\r\n" line endings and Ctrl-Z end-of-file markers myself. If I need to slurp an entire text file into memory, and my code only needs to be portable to POSIX and Windows systems, I think I can assume that the size of the file (determined by whatever means seem appropriate) is an upper bound on the number of bytes I'll read (if I can also assume the file hasn't changed). The file size should at least be a good first approximation of how much data I can read from it. Of course, *always* check results and be prepared for surprises. And I'll acknowledge that there are times when slurping an entire file into memory is a sensible thing to do (and times when it definitely isn't). [...] -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"