On Sun, Aug 21, 2011 at 07:34:04AM +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. > Such code would be very wrong anyway, but theoretically correct, so if,
How is it "very wrong but theoreticaly correct"? It's hard enough for programmers to keep track of an respect the contracts associated with the interfaces they use; are we also expected to make moral judgements about which parts of the contact are "very wrong", all come to the same moral conclusions, and ignore these parts? I mostly agree that it was a bad ideas to mandate/specify this error; in my mind, it belongs under the "may" list rather than the "shall" list. But as it stands, this would be the most efficient way (compared e.g. to fstat()) to determine if you're reading from a socket when you already intend to read anyway. One usage case might be deciding whether to add/strip CR's for a tool (think of something like finger[d]) that could run from inetd speaking a protocol that specifies CR's, or communicating locally with the user or other unix programs where CR's are unwanted. > say, a mainstream piece of software broke if recv() started working on > non-sockets, then there would be a serious case against the change. > > 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. It's legal for an implementation to add error cases, though it may be unwise and result in a low-quality implementation. It's not legal for an implementation to ignore a "shall fail". I make no claim that standards bodies don't sometimes make stupid decisions. But just ignoring them potentially breaks existing software (which of course can be fixed) and (much worse) defeats the principles of interface contracts, which is the *only* way to write non-buggy programs in a language with pointers. Rich _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
