>>> You get ENOBUFS, which SUS says you should not get with blocking I/O.
>> Yes, I think this needs fixing.  But pushing blocking behaviour down
>> to the link layer does not sound to me like the right way to fix it.
> I used to think this (even just 5 minutes ago), but I no longer do.
> It is the documented behavior!

If a gross misfeature is documented, that does not make it any less of
a gross misfeature.  All it means is that both the code and the doc
need fixing.

I'm also not convinced it's what the doc says.  The quote I saw here
from the SUS agrees with the 1.4T and 2.0 send(2) manpages, which say

     If no messages[sic] space is available at the socket to hold the
     message to be transmitted, then send() normally blocks, unless the
     socket has been placed in non-blocking I/O mode.

Note "at the socket".  The lack of space in the case at hand is well
below the socket layer.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B