Bug#165881: telnetd aborts when EAGAIN returned from writev

[GOTO Masanori <gotom@debian.or.jp>]

At Tue, 22 Oct 2002 22:11:27 +1000,
Herbert Xu wrote:
> On Tue, Oct 22, 2002 at 05:57:19AM -0600, John Marvin wrote:
> > 
> > However, the code checks for EWOULDBLOCK, not EAGAIN. Other Unix OS's
> > might use EWOULDBLOCK in this case, but Linux uses EAGAIN. You should
> > not get an EWOULDBLOCK from a write or writev call (I think Linux only
> > uses EWOULDBLOCK for file locking).

SUSv3 says:

[EAGAIN]   Resource unavailable, try again (may be the same value as
           [EWOULDBLOCK]).
[EWOULDBLOCK] Operation would block (may be the same value as [EAGAIN]).
[EWOULDBLOCK]
    Operation would block. An operation on a socket marked as
    non-blocking has encountered a situation such as no data available
    that otherwise would have caused the function to suspend
    execution.  A conforming implementation may assign the same values
    for [EWOULDBLOCK] and [EAGAIN].

So, for some un*x, you should check both EAGAIN and EWOULDBLOCK.
However, dropping check for EWOULDBLOCK is OK, telnetd is not bad if
telnetd hopes such 'good conforming implementation'.

> Looks like a bug in glibc since it's meant to make the two symbols
> identical:
> 
>  - Macro: int EAGAIN
>      Resource temporarily unavailable; the call might work if you try
>      again later.  The macro `EWOULDBLOCK' is another name for `EAGAIN';
>      they are always the same in the GNU C library.
> 
> Why does parisc differentiate the two anyway? Every other Linux
> architecture treats them the same way.

You mean that asm/error.h on linux/parisc says as follows?

#define EWOULDBLOCK     246     /* Operation would block (Linux returns EAGAIN) 

IMHO, it's linux kernel parisc porter's decision, or bug.
I imagine it's related with hpux/parisc, but I don't know.
Ask for parisc maintainers might be gotten the answer.
However, from the standard point of view, it's not wrong.

At least, it's not glibc's bug.

-- gotom