Path: csiph.com!news.swapon.de!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 14:01:07 -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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="16a71c89bad48345b6871a676d7f8d6a"; logging-data="11404"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+pbGgIZhK8ImN25SsFhMGT" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:btCKTgmzecBM8/j6P3DY/wbugr0= sha1:gCJL7Q6B3MLp7iKna9xW9ucouzQ= Xref: csiph.com comp.lang.c:100914 supercat@casperkitty.com 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 don't think the authors of the Standard would have been averse to the idea > that an implementation targeting a file system that does something else > weird might expose such semantics to a C program, but I think they intended > that a programmer who knows how the underlying file system behaves should be > able to make use of that behavior. The question is not what the authors would have been averse to. Certainly behaving in one of the sensible ways you suggest is permitted. The question is what the standard actually requires. If it fails to define the behavior, or a choice of behaviors, then the behavior is undefined. The key is just what the word "requires" means in that context. -- 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"