Path: utzoo!attcan!uunet!aplcen!samsung!usc!apple!oliveb!tymix!cirrusl!dhesi%cirrusl
From: dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi)
Newsgroups: comp.unix.wizards
Subject: stdio/socket interaction
Summary: Does a short return count from read() imply a possible
         short return count from fread() too?  (BSD or SunOS)
Message-ID: <1787@cirrusl.UUCP>
Date: 31 May 90 00:53:06 GMT
Sender: news@cirrusl.UUCP
Reply-To: dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi)
Organization: Cirrus Logic Inc.
Lines: 23

(4.3BSD and/or SunOS 4.0.3)

When reading from a file descriptor connected to a socket (or to a tape
device) the read() system call may return fewer bytes than requested.
Thus if a process wants to read exactly n bytes, it must loop on read()
until it has enough data (or until read() returns 0 bytes indicating
EOF).

Given this, how safe is it to use fdopen() to attach such a file
descriptor to a buffered "FILE *" file?  Is there a possible problem
with fgets(), for example, returning less than a complete line, or
fread() returning fewer items than requested, even if EOF has not been
reached?  Or does the stdio library loop on a read() and always read
the requested number of bytes?

(My SunOS 4.0.3 manual says that "fread() stops reading if an
end-of-file or error condition is encountered while reading from
'stream', or if 'nitems' items have been read," which clearly does not
allow fread() to stop reading merely because read() needs to be called
again.)

Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com>
UUCP:  oliveb!cirrusl!dhesi