> No. If there is a correct behaviour defined in a standard we should
> do that. Otherwise we should do what other systems do _unless_ there
> is a clear benefit to doing something else. In this case doing
> something else appears to create porting problems and confusion over
> what select(2) means without any clear benefit.
> Mike
There is a clear and significant benefit. Bugs that result in a program
calling 'select' on an unconnected socket will be easily and quickly
detected. During debugging, they can then be fixed. During release
execution, they can be worked around.
There are a large number of possible mistakes that can result in this
behavior. A program that heavily uses sockets could sometimes forget to
remove a socket from its active poll/select set. A program might
accidentally close the wrong socket (and that socket might get reused by a
subsequent call to 'socket'). It's nice to have a way to catch these. During
debug, socket errors are routinely logged or displayed, so this would get
caught.
Of course, this isn't so much of a benefit that it's worth violating a
standard like POSIX. But it could be considered enough of a benefit that
it's worth not being compatable outside the bounds of such a standard.
DS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 23 2001 - 21:00:51 EST