Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Reading lines from a file, eliminating CR and LF Date: Mon, 02 Jan 2017 16:49:45 -0800 Organization: None to speak of Lines: 43 Message-ID: References: <9a6e5204-d031-4070-88cb-8132072c5c68@googlegroups.com> <7285df88-1603-4edb-abba-b9c5e4172d34@googlegroups.com> <6e6aace3-d1e8-4be3-aa16-e99032ee1fba@googlegroups.com> <5d417a85-145c-46c5-b08c-bb3ee88007b9@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="f1ffbb62f7d4ea154aec5923c7307730"; logging-data="11404"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/y3hUuDt3h7k/sDqlW7Lkq" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:AuaBB29kmYnSlPhre0cqfBJmj10= sha1:hFVEDTxO/jFxVWvkGL/dB5tdSxc= Xref: csiph.com comp.lang.c:100941 supercat@casperkitty.com writes: > On Monday, January 2, 2017 at 4:00:43 PM UTC-6, Keith Thompson wrote: >> supercat writes: >> [...] >> > There are three ways that typical file systems might handle an attempt to >> > write some data without a trailing newline prior to closing a file: >> > >> > 1. Produce a file which, when read, will appear to contain precisely the >> > data that was written, with no trailing newline. >> > >> > 2. Produce a file which, when read, will appear to contain all of the data >> > that was written, possibly excluding trailing padding at the ends of >> > lines, with a newline added to complete the last partial line. >> > >> > 3. Produce a file like the above, but with the last partial line omitted >> > (I don't know if file systems worked like that, but some printers work >> > that way if programs reset them before beginning operation). >> >> Those are hardly the only possibilities. >> >> 4. Produce a file that is not a valid text file. Attempting to open it >> using fopen() with a mode argument of "r" will fail (possibly setting >> errno to indicate something like "not a text file", though the standard >> doesn't require that) -- *or* attempting to read data from the file will >> at some point fail and cause ferror() to return nonzero. > > I said a "typical file system". Are you aware of any file systems that > could be reasonably described as "typical" which do not behave in one > of the above fashions? No, I'm not -- but there are plenty of file systems I'm not familiar with. I'm talking about what the Standard requires. You're talking about what you expect typical implementations to do. They're two different things. [...] -- 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"