Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #65638

Re: Fgets question

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>

Show all headers | View raw


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


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