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 : [email protected]
LUGA : http://www.luga.at
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
