From owner-freebsd-hackers Fri Apr 12 15:55:34 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA26028 for hackers-outgoing; Fri, 12 Apr 1996 15:55:34 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA26009 for ; Fri, 12 Apr 1996 15:55:30 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id IAA03590; Sat, 13 Apr 1996 08:50:47 +1000 Date: Sat, 13 Apr 1996 08:50:47 +1000 From: Bruce Evans Message-Id: <199604122250.IAA03590@godzilla.zeta.org.au> To: koshy@india.hp.com, nate@sri.MT.net Subject: Re: Critical stdio bug? Cc: hackers@freebsd.org 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. This is normal (wrong) BSD behaviour. EOF is sticky, even on a terminal. You have to clear the EOF using clearerr(). See the getc man page. >The manual page says: ^ for read() > 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 Input using stdio is quite different from input using read(), unfortunately. Bruce