Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Mon, 18 Oct 2004 18:57:44 -0700
From: Yitzchak Scott-Thoennes <sthoenna AT efn DOT org>
To: cygwin AT cygwin DOT com
Subject: Re: [OT] RE: Expected behaviour of fgets on stdin after a EOF ?
Message-ID: <20041019015743.GA3572@efn.org>
References: <NUTMEGLsxpTljBOh8s400000033 AT NUTMEG DOT CAM DOT ARTIMI DOT COM> <NUTMEGWiGtXsL1c00go00000034 AT NUTMEG DOT CAM DOT ARTIMI DOT COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <NUTMEGWiGtXsL1c00go00000034@NUTMEG.CAM.ARTIMI.COM>
User-Agent: Mutt/1.4.1i
Organization: bs"d
X-IsSubscribed: yes

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/