This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [OT] RE: Expected behaviour of fgets on stdin after a EOF ?


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]