Mail Archives: cygwin/2004/10/18/21:57:56
On Mon, Oct 18, 2004 at 07:09:11PM +0100, Dave Korn wrote:
> For the serious answer, see the SUS definition of fgets...
>
> http://www.opengroup.org/onlinepubs/009695399/functions/fgets.html
>
> (although for preference you really want to refer to the C language spec, to
> which the SUS defers: nonetheless, they're both in fairly clear agreement
> that) once the input stream has reached EOF, the c library should set an
> end-of-file-indicator in the stream (FILE struct) and not start returning
> more input.
>
> > Looks like (confirmed with GDB), that fgets is no longer
> > blocking after
> > the EOF, and keeps returning the same NULL value, while it's
> > blocking on other platforms I've mentioned.
>
> This is consistent with what the spec requires:
FWIW, I don't read the spec at all that way.
> "Description
> 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."
>
> That says to me that anytime after you've received an EOF, fgets is not
> allowed to read or return "additional characters".
That para is just talking about what a single call to fgets does; I don't
think it says anything about what a future call to fgets should do.
> "Returns
> 3 The fgets function returns s if successful. If end-of-file is encountered
> and no characters have been read into the array, the contents of the array
> remain unchanged and a null pointer is returned. If a read error occurs
> during the operation, the array contents are indeterminate and a null
> pointer is returned"
>
> That says to me that once EOF has been reached, it should stay EOF'd.
Again, I don't see anything there to make me think it's talking about
more than just the current fgets call.
I would expect all reading functions to behave the same wrt eof, so
I would be surprised to find this kind of thing documented in just one
of them.
However, in read/pread there is:
No data transfer shall occur past the current end-of-file. If the
starting position is at or after the end-of-file, 0 shall be
returned. If the file refers to a device special file, the result
of subsequent read() requests is implementation-defined.
And this may be of interest:
void clearerr(FILE *stream);
DESCRIPTION
...
The clearerr() function shall clear the end-of-file and error
indicators for the stream to which stream points.
A clearerr does "fix" the "problem" in the test program.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -