From owner-freebsd-hackers  Fri Apr 12 08:46:13 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id IAA12218
          for hackers-outgoing; Fri, 12 Apr 1996 08:46:13 -0700 (PDT)
Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id IAA12198
          for <hackers@freebsd.org>; Fri, 12 Apr 1996 08:46:09 -0700 (PDT)
Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id JAA07272; Fri, 12 Apr 1996 09:42:08 -0600
Date: Fri, 12 Apr 1996 09:42:08 -0600
From: Nate Williams <nate@sri.MT.net>
Message-Id: <199604121542.JAA07272@rocky.sri.MT.net>
To: A JOSEPH KOSHY <koshy@india.hp.com>
Cc: Nate Williams <nate@sri.MT.net>, hackers@freebsd.org
Subject: Re: Critical stdio bug? 
In-Reply-To: <199604120837.AA276558230@fakir.india.hp.com>
References: <199604120530.XAA06324@rocky.sri.MT.net>
	<199604120837.AA276558230@fakir.india.hp.com>
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> 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?

I'm not confident to answer thjis, but I suspect the author (Chris
Torek) would know. :)

I'll forward him all of the relevant material in a separate email.


Nate