Date: Fri, 12 Apr 1996 09:42:08 -0600 From: Nate Williams <nate@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? Message-ID: <199604121542.JAA07272@rocky.sri.MT.net> In-Reply-To: <199604120837.AA276558230@fakir.india.hp.com> References: <199604120530.XAA06324@rocky.sri.MT.net> <199604120837.AA276558230@fakir.india.hp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604121542.JAA07272>