make send()/recv() work on sockets (was Re: [PATCH] ash: clear NONBLOCK flag from stdin when in foreground)

Bernd Petrovitsch bernd at petrovitsch.priv.at
Sun Aug 21 07:07:10 UTC 2011


Hi!

Sorry for self-replying - -ETOOEARLYFORCREATIVITY

On Son, 2011-08-21 at 09:03 +0200, Bernd Petrovitsch wrote:
> On Son, 2011-08-21 at 07:34 +0200, Laurent Bercot wrote:
> > > ERRORS
> > > 
> > > The recv() function shall fail if:
> > > 
> > > [ENOTSOCK]
> > > The socket argument does not refer to a socket.
> >
> >  Is there any code that relies on this ? i.e. code that tests whether
> > a fd is a socket by recv()ing on it and testing the error code, if any.
> 
> I don't know of any and I don't know why some software may want to know
> that so that they call revc() on it (and possibly get some data).
> Using getsockname() on it make vastly more sense as it doesn't change
> anything on the fd/socket.
> 
> >  Such code would be very wrong anyway, but theoretically correct, so if,
> > say, a mainstream piece of software broke if recv() started working on
> > non-sockets, then there would be a serious case against the change.
>
> Hmm, is there an process-specific means to stay
> POSIX/backwards-compatible?

Hmm, some special new flag - MSG_WORKONFILES or so - which actually
activates that behaviour?

> >  As it stands, Linux has deviated from the standard before, especially
> > about syscall application domains and error codes. I have seen close()
> > return EINVAL for instance.

	Bernd
-- 
Bernd Petrovitsch                  Email : bernd at petrovitsch.priv.at
                     LUGA : http://www.luga.at



More information about the busybox mailing list