Xref: utzoo comp.unix.programmer:2177 comp.unix.questions:32498
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!samsung!olivea!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.programmer,comp.unix.questions
Subject: Re: why would a socket read() set errno to EWOULDBLOCK but still read?
Message-ID: <8632@auspex.auspex.com>
Date: 30 Jun 91 01:30:13 GMT
References: <1991Jun27.220701.21108@athena.mit.edu> <4597@polari.UUCP> <1991Jun28.195655.25623@odin.corp.sgi.com>
Followup-To: comp.unix.programmer
Distribution: usa
Organization: Auspex Systems, Santa Clara
Lines: 43

>Brian> |   I am doing a read() on a connected TCP socket (BSD 4.3) marked as
>Brian> |non-blocking. For some reason, the read returns the proper number of
>Brian> |characters read (or sometimes 0), but sets errno to EWOULDBLOCK.
>
>Brian> Errno is only valid if the read fails.  If the read succeeds, the
>Brian> value of errno shouldn't be used.
>
>i think the original poster is knowledgable enough to know that.
>read() on a non-blocking socket can still return EWOULDBLOCK if
>the amount of bytes read is less than the amount of bytes requested.

Your second sentence contradicts your first, if I'm correctly
interpreting the second sentence as saying "a read on a non-blocking
socket can read some non-zero number of bytes less than the number of
bytes requested, return as its return value the number of bytes
returned, *and* set 'errno' to EWOULDBLOCK."

Of the two, I'll go for the first sentence, given that in many UNIX
implementations - all the ones with which I'm familiar - "errno" is set
by a lump of code that also forces the return value of the routine that
did the trap to be -1.

I.e., if "errno" is set, -1 is returned, period, end of discussion.

There may well be implementations where that's not done, but the SunOS
implementation works that way on 68K and SPARC machines (and probably
386i's as well), as does the 4.3-reno implementation on VAX, Tahoe, 68K,
and i386) and the System V Release 3 implementation on the WE32K.  (In
fact, the lump of code in question is good old "cerror" - modulo the
presence or absence of some number of leading underscores - a name
dating, as I remember, all the way back to the PDP-11....)

Yes, a "read()" on a non-blocking socket can return a byte count lower
than the number of bytes requested.  So can a "read()" on a blocking
socket, or on a plain ordinary boring file, for that matter.  However,
in *NO* UNIX implementation with which I'm familiar will it change the
value of "errno" if it does that!

I.e., if "read()" doesn't return -1, *don't assume "errno" is telling
you anything about the read* - it's almost certainly *not* doing so.  If
it *happens* to contain EWOULDBLOCK, that's because the last call that
*did* return an error indication set it to EWOULDBLOCK, whatever that
call was....