From owner-freebsd-hackers  Fri Apr 12 01:33:21 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id BAA12010
          for hackers-outgoing; Fri, 12 Apr 1996 01:33:21 -0700 (PDT)
Received: from paloalto.access.hp.com (daemon@paloalto.access.hp.com [15.254.56.2])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id BAA11995
          for <hackers@freebsd.org>; Fri, 12 Apr 1996 01:33:13 -0700 (PDT)
Received: from fakir.india.hp.com by paloalto.access.hp.com with ESMTP
	(1.37.109.16/15.5+ECS 3.3) id AA086987981; Fri, 12 Apr 1996 01:33:06 -0700
Received: from localhost by fakir.india.hp.com with SMTP
	(1.37.109.16/15.5+ECS 3.3) id AA276558230; Fri, 12 Apr 1996 14:07:11 +0530
Message-Id: <199604120837.AA276558230@fakir.india.hp.com>
To: Nate Williams <nate@sri.MT.net>
Cc: hackers@freebsd.org
Subject: Re: Critical stdio bug? 
In-Reply-To: Your message of "Thu, 11 Apr 1996 23:30:23 CST."
             <199604120530.XAA06324@rocky.sri.MT.net> 
Date: Fri, 12 Apr 1996 14:07:10 +0530
From: A JOSEPH KOSHY <koshy@india.hp.com>
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


>>>>> "nw" == "Nate Williams" >>>>>

nw> OS's, but I had them available).  However, on FreeBSD the EOF doesn't
nw> get flushed out when it's read.

The program works correctly on some HPUX machine I could lay my hands on
too.

The behaviour seems to be coming from: "lib/libc/stdio/refill.c";__srefill(fp)
	                
	/* SysV does not make this test; take it out for compatibility */
	if (fp->_flags & __SEOF)
			return (EOF);
			 
The problem seems to be here (further down in the function) : 

        fp->_r = (*fp->_read)(fp->_cookie, (char *)fp->_p, fp->_bf._size);
        fp->_flags &= ~__SMOD;  /* buffer contents are again pristine */
        if (fp->_r <= 0) {
                if (fp->_r == 0)
                        fp->_flags |= __SEOF;
                else {
                        fp->_r = 0;
                        fp->_flags |= __SERR;
                }
                return (EOF); 
        }


The manual page says:

	The system guarantees to read the number of bytes requested if 
	the descriptor references a normal file that has that many bytes 
	left before the end-of-file, but in no other case.
	[...]
	If successful, the number of bytes actually read is returned. Upon read-
	ing end-of-file, zero is returned.  Otherwise, a -1 is returned and the

Thus getting a return count of 0, does not always imply end-of-file forever
on the file descriptor.  

So isn't the check at the beginning of the function incorrect?

Koshy