Path: csiph.com!usenet.pasdenom.info!gegeweb.org!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Fgets question Date: Wed, 15 Jul 2015 10:42:41 -0700 Organization: None to speak of Lines: 68 Message-ID: References: <0b5d570e-eed5-4162-b5f9-44b2058639ee@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="7987"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/f2mxxV0T5D5/RUc/ExAu7" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:Y5BTR2qzsztbC9lijw07HSbTZ2w= sha1:Xyc/vV2clBNKwboiQydvUUDLu5c= Xref: csiph.com comp.lang.c:65638 Tim Rentsch writes: > Keith Thompson writes: >> Tim Rentsch writes: >>> Keith Thompson writes: >> >> [...] >> >>>> *However* the description of text streams in 7.21.2 says that a trailing >>>> new-line may be required. (By implication, if there is no new-line at >>>> the very end of the file, the behavior is undefined.) [snip] >>> >>> FWIW I think you may be reading that wrongly. The requirement is not >>> on the program but on the line. ("Whether the last line requires a >>> terminating new-line character is implementation-defined.") It's >>> not obvious that leaving off a final new-line was meant to be (or >>> was meant not to be) undefined behavior. >> >> Can you clarify what a requirement *on the line* means? >> Implementations have behavior; lines don't. I think it's just >> slightly odd wording. In any case, it's the implementation that >> has to specify whether it's required or not. > > I agree the wording is odd. At some level that's the point I'm > making, that the odd wording may portend an unexpected meaning or > interpretation. For example, the sentence quoted above might > mean "Whether the last line requires a terminating new-line > character _to be considered part of the text stream_ is > implementation-defined." Thus any characters sent after the last > newline transmitted simply are not part of the text stream. That's certainly one possible behavior. But the standard doesn't say that that's how it behaves, and I don't think it's reasonable to assume that that one specific behavior is what was intended. For an implementation where the last line "requires" a terminating new-line, it would be equally reasonable for an fgets() call on the last line to behave as if the new-line character were there. Or, on a system where text files are not represented as simple byte streams as they are on Unix, a text file without a terminating new-line on the last line might be ill-formed, and an fgets() call might return an error indication -- perhaps even before attempting to read the last line. (I probably should have written that in terms of fgetc(), since the behavior of fgets() is defined in terms of readin characters, but I'm too lazy to go back and change it.) In fact, the standard doesn't say what the behavior is at all -- which is, by definition, undefined behavior. >> If, for a given implementation, the last line doesn't require a >> terminating new-line, writing a text file with no newline and then >> reading it has well defined behavior. If the last line *does* >> require it, then the standard doesn't say what the behavior of a >> program that omits it is -- thus, undefined behavior. > > If the last line requires a newline to be considered part of a > text stream, then not sending a final newline simply means the > last line isn't included in the output. That is a definition of > behavior, even if it is not stated as explicitly as we would > like. Note that I am not saying that the Standard _must_ mean > this, only that it _might_ mean this. At this point I haven't > seen any compelling evidence to decide the matter either way. -- 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"