Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/17/84; site gang.UUCP
Path: utzoo!linus!decvax!bellcore!allegra!ulysses!mhuxr!ihnp4!gang!hokey
From: hokey@gang.UUCP (Hokey)
Newsgroups: net.unix-wizards
Subject: Questions about read() and write()
Message-ID: <532@gang.UUCP>
Date: Sat, 22-Dec-84 01:42:10 EST
Article-I.D.: gang.532
Posted: Sat Dec 22 01:42:10 1984
Date-Received: Sun, 23-Dec-84 08:04:16 EST
Distribution: net
Organization: Plus Five Computer Services, St. Louis
Lines: 29

While rewriting an application to provide for robust error handling of
read() and write() calls, I noticed the manual page for SysV says a few
strange things about read().

For starters, the function returns an int.  One passes an unsigned number
of bytes which specifies the maximum number of characters which should be
returned.  The return value is a non-negative integer indicating the actual
number of bytes read, or -1.  If this is true, why is the number of bytes
an unsigned quantity?

Write() is similarly documented to a lesser degree.

Nextly, what happens to the current file position if a read() or write() is
interrupted?  This is another non-documented issue, near as I can tell.
Should another lseek() be issued when restarting one of these calls (when
dealing with disk files)?

If so, one must be careful when reading or writing to disk files when doing
realtive lseek()s.

What happens if, under 4.2, an alarm call causes the read() or write() to
be restarted for me (is there a good reason why this was changed in 4.2)?

I am interested in information pertaining to this gluck for V7, Sys{III,V},
and {2,4}BSD.

-- 
Hokey           ..ihnp4!plus5!hokey
		  314-725-9492