cvs commit: src/sys/kern uipc_socket.c

[John Baldwin]

On Tuesday 07 October 2008 04:57:55 pm Robert Watson wrote:
> rwatson     2008-10-07 20:57:55 UTC
> 
>   FreeBSD src repository
> 
>   Modified files:
>     sys/kern             uipc_socket.c 
>   Log:
>   SVN rev 183675 on 2008-10-07 20:57:55Z by rwatson
>   
>   In soreceive_dgram, when a 0-length buffer is passed into recv(2) and
>   no data is ready, return 0 rather than blocking or returning EAGAIN.
>   This is consistent with the behavior of soreceive_generic (soreceive)
>   in earlier versions of FreeBSD, and restores this behavior for UDP.
>   
>   Discussed with: jhb, sam
>   MFC after:      3 days

I do find this behavior odd though.  I would expect

	recv(fd, NULL, 0)

to discard the next packet from the socket if one is available rather than 
returning success and not doing anything (and it seems that this is what it 
does both before and now).  Similarly, I would expect recv(fd, NULL, 0) to 
block on a blocking socket if there isn't a packet available.  It would be 
orthogonal then to return EAGAIN in this case (no packet available, 
zero-length user buffer) on a non-blocking socket.

It seems that Solaris dropped this behavior (return 0) from their recv() 
system call sometime after SunOS 4.0 from comments in the OpenSolaris source.  
From reading __skb_recv_datagram(), it seems that Linux 2.6 returns EAGAIN.  
NetBSD and OS X both have the odd behavior.  OpenBSD has the odd behavior, 
but with a caveat of sorts having to do with control messages.  OpenBSD 
cvsweb annotate is down though, so I haven't found the reason for their 
change.

-- 
John Baldwin