Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Fgets question |
| Date | 2015-07-15 10:42 -0700 |
| Organization | None to speak of |
| Message-ID | <lnpp3tjp0u.fsf@kst-u.example.com> (permalink) |
| References | <0b5d570e-eed5-4162-b5f9-44b2058639ee@googlegroups.com> <lnpp44c1bq.fsf@kst-u.example.com> <kfnfv4u28k0.fsf@x-alumni2.alumni.caltech.edu> <lnr3oepfri.fsf@kst-u.example.com> <kfnr3o9qtds.fsf@x-alumni2.alumni.caltech.edu> |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> Keith Thompson <kst-u@mib.org> 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 <http://www.ghoti.net/~kst>
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"
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Fgets question Paul N <gw7rib@aol.com> - 2015-07-06 14:06 -0700
Re: Fgets question Barry Schwarz <schwarzb@dqel.com> - 2015-07-06 15:09 -0700
Re: Fgets question Keith Thompson <kst-u@mib.org> - 2015-07-06 16:41 -0700
Re: Fgets question Paul N <gw7rib@aol.com> - 2015-07-07 15:16 -0700
Re: Fgets question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-06 23:13 +0100
Re: Fgets question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-07 00:57 +0100
Re: Fgets question Keith Thompson <kst-u@mib.org> - 2015-07-06 16:29 -0700
Re: Fgets question Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 05:16 -0700
Re: Fgets question Keith Thompson <kst-u@mib.org> - 2015-07-11 14:04 -0700
Re: Fgets question Richard Damon <Richard@Damon-Family.org> - 2015-07-11 19:56 -0400
Re: Fgets question Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 09:26 -0700
Re: Fgets question Keith Thompson <kst-u@mib.org> - 2015-07-15 10:42 -0700
Re: Fgets question Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 10:53 -0700
Re: Fgets question Keith Thompson <kst-u@mib.org> - 2015-07-20 12:51 -0700
Re: Fgets question Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-24 10:10 -0700
Re: Fgets question Keith Thompson <kst-u@mib.org> - 2015-07-24 12:15 -0700
Re: Fgets question Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-26 16:41 -0700
Re: Fgets question Keith Thompson <kst-u@mib.org> - 2015-07-27 11:42 -0700
Re: Fgets question Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 15:42 -0700
csiph-web