why would a socket read() set errno to EWOULDBLOCK but still read?

[der Mouse]

In article <1991Jun27.220701.21108 at athena.mit.edu>, mlevin at jade.tufts.edu writes:

> I am doing a read() on a connected TCP socket (BSD 4.3) marked as
> non-blocking.  For some reason, the read returns the proper number of
> characters read (or sometimes 0), but sets errno to EWOULDBLOCK.

You must be mistaken about something.  4.3 read() never sets errno
unless it returns -1.  In support of this, the source, stripped of
junk:

	#include "SYS.h"
	SYSCALL(read)
		ret

After preprocessing, this expands into

		.globl	cerror
	err:	jmp	cerror
		.globl	_read
		.align	2
	_read:	.word 0
		chmk	$3
		jcs	err
		ret

In another file, we have

		.globl	_errno
	cerror:
		movl	r0,_errno
		mnegl	$1,r0
		ret

Notice that errno is never affected except under circumstances which
cause read to return -1.  (The kernel does not have direct access to
the user-level errno variable.)

(Before you take me to task for citing assembly code, note that 4.3
requires a VAX to run.  If you're not on a VAX, you're running either
something later - 4.3-tahoe is an example - or something else, perhaps
a derivative or port of 4.3.)

Are you sure you're really using 4.3, not a 4.3 derivative of some
sort?

For that matter, are you sure it's setting errno?  The errno value
might be left over from something else.

Besides all that, if read() doesn't return an error, the value of errno
is unspecified; it may be EWOULDBLOCK, it may be EFAULT, it may be
ELOOP, for that matter.  The value of errno is *not meaningful* except
after a failed call documented to set errno and before the next call
which does not promise to preserve errno.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse at larry.mcrcim.mcgill.edu