Date: Fri, 12 Apr 1996 14:07:10 +0530 From: A JOSEPH KOSHY <koshy@india.hp.com> To: Nate Williams <nate@sri.MT.net> Cc: hackers@freebsd.org Subject: Re: Critical stdio bug? Message-ID: <199604120837.AA276558230@fakir.india.hp.com> In-Reply-To: Your message of "Thu, 11 Apr 1996 23:30:23 CST." <199604120530.XAA06324@rocky.sri.MT.net>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> "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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604120837.AA276558230>