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 13:15:31 -0800 Organization: None to speak of Lines: 74 Message-ID: References: <9a6e5204-d031-4070-88cb-8132072c5c68@googlegroups.com> <7285df88-1603-4edb-abba-b9c5e4172d34@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="U2FsdGVkX19b3k1HCaWHglUiAFTRiHpn" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:4xMekQyJC39Nm94hIU9nfrA3Sdo= sha1:Dov3EU7IbERgzzBo/bIXougjWfk= Xref: csiph.com comp.lang.c:100908 Tim Rentsch writes: > Keith Thompson writes: >> Tim Rentsch writes: >>> Keith Thompson writes: >> [...] >> >>>> The C standard says that for a text stream, it's implementation-defined >>>> whether the final line requires a trailing '\n'. If it *is* required by >>>> the current implementation, the behavior of reading a text file with no >>>> '\n' on the last line is undefined. [...] >>> >>> That is one plausible interpretation. >>> >>> Another plausible interpretation is that the situation described >>> simply cannot exist. If a file is closed with a non-empty last >>> line, but no newline, then that last line is either discarded or >>> it is written with a newline appended. The file system may have >>> no way to represent a text file with a non-empty last line but >>> without a trailing newline; or, if it does, an attempt to read >>> such a line may read nothing and return EOF, or it may give the >>> line with a newline appended. And which of these alternatives is >>> meant to hold must be specified as part of the documentation that >>> specifies what the implementation-defined requirement means in >>> this implementation. >> >> The relevant wording, N1570 7.21.2p2, is: >> >> A text stream is an ordered sequence of characters composed into >> lines, each line consisting of zero or more characters plus a >> terminating new-line character. Whether the last line requires >> a terminating new-line character is implementation-defined. >> >> I find that second sentence a bit sloppy. On what entity is that >> requirement imposed? > > That question assumes the statement is meant to impose a > restriction rather than just reflecting some external limitation, > eg, of the underlying OS's file system. I believe it merely assumes that the word "requires" means "requires". [...] >> On a Unix-like system, a file is a sequence of bytes, and *any* >> file can be a valid text file (possibly containing one very >> long unterminated line). On other systems, text files are more >> restricted. On Windows, if I write "foo\n\r" to a file in binary >> mode, the result is not a valid text file (actually I'm not sure >> of that, but one can imagine similar scenarios on other systems). >> I suggest that, on a system that requires that terminating new-line, >> writing "foo" to a file can create something that is not a valid >> text file. > > Your last statement is true but irrelevant, because that can > happen in any implementation whether the last line of a text file > requires a newline or not. The question is how much latitude > does an implementation have in such a case? I believe that such > cases are not meant to be undefined behavior, but are limited to > the behaviors documented as part of the implementation-defined > property associated with final newlines for text files. If such cases are not meant to be undefined behavior, but the standard fails (intentionally or not) to define the behavior, then the behavior is undefined. What "implementation-defined property" are you referring to? If it's implementation-defined, there's a specific requirement in the standard for the behavior to be documented. -- 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"