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