Re: sorting the input

Barry Schwarz <schwarzb@xxxxxxxx> writes:

On Fri, 25 Apr 2008 14:26:35 +0100, Ben Bacarisse
<ben.usenet@xxxxxxxxx> wrote:

Barry Schwarz <schwarzb@xxxxxxxx> writes:
<snip>
This in no way affects the portable behavior of fgets. If the amount
of data in the "line" leaves at least two unused bytes in the buffer,
fgets MUST terminate the string with a '\n' followed by a '\0'.
Failure to do so violates the required performance specified in the
standard.

Not by my reading of it. It seems entirely within the allowed
behaviour that the last line (i.e. the one that triggers the
end-of-file condition) might not leave a \n in the buffer. In fact,
both reading a newline and seeing the end of the file are listed as
reasons to stop input and null-terminate the string. Am I missing
something?

I think we are using the term buffer in two different senses. I used
buffer to mean the "array" pointed to by the first argument to fgets.
You appear to be using it to refer to the I/O buffer used to manage
the stream. In that case I agree with you. I make no claim as to the
contents of the stream buffer.

No, I am talking about the same buffer as you. I, too, make no claims
about any intermediate stream buffers.

What I do claim is that santosh's
assertion that two end of file sequences (whatever that is)

[It is just how some systems let you signal an end-of-file when the
preceding input is not a newline. Thus, on Linux, to give a program a
three-byte input stream consisting of 'a', 'b' and 'c' you would type
"abc^D^D" at it.]

can
prevent fgets from storing a '\n' in the array buffer would a
violation of the standard. Ignoring error conditions, if the number
of bytes read is at least two less than the second argument to fgets,
then fgets must store both '\n' and '\0' in sequence immediately
following the last byte read. Failure to do so is a violation of its
behavior mandate.

All I can say is that is not how I read that part of the standard.
The governing text seems to be section 7.19.7.2 para. 2:

"The fgets function reads at most one less than the number of
characters specified by n from the stream pointed to by stream into
the array pointed to by s. No additional characters are read after a
new-line character (which is retained) or after end-of-file. A null
character is written immediately after the last character read into
the array."

which I can't read as mandating a newline being added to the buffer
unless one was there in the first place. The only place where there
may not be one is of course, by definition, the last line.

If you are right, and there are further restrictions that mandate a
newline character (space permitting) in the last successful return
from fgets, then gcc's fgets is not conforming (as are several other C
libraries I have used before but no longer have access to).

Of course, it is permissible for an implementation to require that the
last line of all text streams include a newline. So the behaviour you
say is required by the standard may be imposed by an implementation;
but this is "optional" and, in any case, would only apply to text
streams.

--
Ben.
.

Relevant Pages

  • Stateful character decoder?
    ... a decoder that will cache incomplete characters so that the caller can simply discard its entire input after calling the decoder. ... If you want to treat your input as a character stream, you've got a couple of very convenient options: InputStreamReader and BufferedReader. ... The problem with the latter is that using a CharsetDecoder explicitly means that if you get a partial character at the end of the current input buffer, you have to preserve those bytes and resubmit them to the decoder on the next try. ...
    (comp.lang.java.programmer)
  • Re: Finding start and end of data in a stream
    ... So then on the client end it has a receive buffer of 1024 bytes. ... gap of x many bytes of empty data in receive buffer then the final 250bytes. ... In a binary stream how do i tell my client when the second 250 ... As lxRob said simialr to an end character i could put in a start character ...
    (microsoft.public.win32.programmer.networks)
  • Re: Mixing text and binary I/O
    ... In case of complex encodings like UTF-8, ... readBytereads from the buffer, handles buffering of new data, etc. ... "Fixup" the fact that one character ... the stream can have a UTF-8 character (encoded by ...
    (comp.lang.java.programmer)
  • Re: Null-terminated strings: the final analysis.
    ... If you use fgets, you can see any '\0' that you had previously written, ... prefilling the buffer and calling fgets, you can scan the buffer backwards ... Whether a text file requires a new-line character on the last line is ...
    (comp.lang.c)
  • Re: Null-terminated strings: the final analysis.
    ... If you use fgets, you can see any '\0' that you had previously written, ... prefilling the buffer and calling fgets, you can scan the buffer backwards ... It is clear that NUL in a text stream corrupts the string. ... Handling the last line without '\n' is trivial: If fgets returns non-null, the first '\0' in the buffer will have been placed there by fgets after the last character read from the stream. ...
    (comp.lang.c)