Not a typewriter

[Ed Gould]

>>This is true. *However*, if you look at the documentation *carefully*, you
>>will find that it says that errno is only valid if the system call preceeding
>>it returned an error value.
>
>Well, there is an exception. If a read or write is interrupted by
>a signal, it will return 0 or number of bytes written before the
>interrupt occured. In this case errno = 4, and no error code is
>returned from the system call.

As long as we're reading the documentatin *carefully*, let's remember that
any return from

	write(fd, buf, n)

that is != n is an error.

This leaves only the interrupted

	read(fd, buf, n)

which could return with "no error code" returned.  Reads from fast
devices (e.g. disks) can't be interrupted.  Reads from slow devices
(e.g. ttys) can be interrupted, but not if they've caused any data to
be transferred.  That's because once there is data available, it will be
transfered to the user and the call will return.

Read() will return one of four values: <0 if error, 0 if EOF, 0<k<n if
only k bytes were available to be read (typically because the k'th byte was
a delimiter like newline or we were positioned k bytes before EOF), or
n if >= n bytes were available.  I can't test this here, since I'm
running 4.2BSD which will restart the read(), but if I remember
correctly back to V7 and 4.1, only the <0 case will cause errno to be
altered.

So what is the case that sets errno without returning an error indication?
The *only* legitimate time to use errno is after an error return from
a system call, or from a library routine that is explicitly documented
to set errno on error.

EIEIO	"Bug bug here. Bug bug there.  Here a bug, there a bug.
	Everywhere a bug bug."

-- 
Ed Gould                    mt Xinu, 2910 Seventh St., Berkeley, CA  94710  USA
{ucbvax,decvax}!mtxinu!ed   +1 415 644 0146

"A man of quality is not threatened by a woman of equality."