Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!linus!decvax!genrad!mit-eddie!godot!harvard!seismo!brl-tgr!gwyn From: gwyn@brl-tgr.ARPA (Doug Gwyn) Newsgroups: net.unix-wizards Subject: Re: Questions about read() and write() Message-ID: <6778@brl-tgr.ARPA> Date: Wed, 26-Dec-84 01:06:15 EST Article-I.D.: brl-tgr.6778 Posted: Wed Dec 26 01:06:15 1984 Date-Received: Thu, 27-Dec-84 05:42:13 EST References: <532@gang.UUCP> Distribution: net Organization: Ballistic Research Lab Lines: 23 > 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. That's right; this bogosity is required for backward compatibility. I advise not telling read() or write() to handle more bytes than can be expressed in an int. > Nextly, what happens to the current file position if a read() or write() is > interrupted? Filesystem I/O is not interrupted by signals. > 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/O to/from a slow device (e.g. terminal) is automatically restarted by 4.2BSD. This was somebody's "better idea" that breaks existing code. You can avoid the automatic system call restart by some kludgery first described by Donn Seeley and posted by me several months ago.