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

Groups > comp.lang.c > #66050

Re: Fgets question

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:
>>>> 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.
>
> You keep saying that the Standard doesn't say what the behavior
> is and therefore that the result is undefined behavior.

Yes.

> My position is that the Standard /may/ say what the behavior is,
> depending on how one interprets the key sentence in question.
> Certainly if the Standard does say what the behavior is then
> the behavior is not undefined.
>
> I agree that there are different ways of interpreting the key
> sentence mentioned, and I agree that different people might
> reach different conclusions about whether what the Standard
> says should be construed to ascribe some particular behavior
> in such cases.  I think we both agree that the existing wording
> is somewhat murky and merits clarification.  Having said all
> that, I think it's wrong to say categorically the such cases
> must be undefined behavior, because what the Standard has to say
> on that question may depend on how one interprets all the
> relevant passages.

To repeat the relevant passage (N1570 7.21.2p2):

    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.

For an implementation where the last line "requires" a terminating
new-line character, you suggest that the implementation could ignore any
characters following the last new-line.  It's equally possible that an
implementation could behave as if the terminating new-line were there,
so you could write "hello" to a text stream and then read "hello\n" from
the same text stream.  I see no clue in the standard that either
behavior is preferred over the other -- or over any of a number of other
plausible behaviors.

There may have been some *intent* to define the behavior, but the
standard just doesn't do so.

I agree that that passage is badly worded, even if the intent is for the
behavior to be undefined.

Incidentally, I find it plausible that the behavior is intended to be
undefined.  I can imagine an system where a text file *must*
have a new-line on the last line, and reading a file that violates that
could have bad consequences.  I think the committee intended to allow
conforming implementations for such systems.

The following paragraph discusses binary streams, and a similar
consideration for what the end of such a stream looks like.  For binary
streams, the standard explicitly makes the behavior
implementation-defined:

    Such a stream may, however, have an implementation-defined
    number of null characters appended to the end of the stream."

The failure to do so for text streams might have been an unintentional
oversight, but it's plausible that it was deliberate.

The bottom line is that I disagree with your assertion that the standard
might define the behavior for text streams.  By my reading, it simply
doesn't.

-- 
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