Re: Bug#752237: libc0.3: send() asked to transmit 0 chars still triggers recv() on Hurd

[Richard Braun]

On Sat, Jun 21, 2014 at 03:56:46PM +0200, Andreas Cadhalpun wrote:
> This is because the client is calling:
>       send(sockfd, "", 0, 0)
> 
> Normally this doesn't trigger recv() in the server and thus can be
> used to test, whether the socket is working.
> But on Hurd it actually sends an empty message, so that the real
> message, which is sent later, is not received.

Hello,

Thanks for the report. There are actually two sides of the problem.
First, I agree that there seems to be a bug, but let's take a closer
look at the spec. The return value for recv() is defined as :

"Upon successful completion, recv() shall return the length of the
message in bytes. If no messages are available to be received and the
peer has performed an orderly shutdown, recv() shall return 0."

This doesn't creates a strict equivalence between "orderly shutdown" and
"shall return 0". But in practice, this seems to be the actual
assumption, so let's say that there is indeed a Hurd bug here. By the
way, although the send() and recv() functions themselves (in glibc) may
benefit from additions to filter out empty messages (at least send()),
the server functions are those found in pflocal concerning AF_UNIX
sockets.

But there is also a bug in the client code, IMO. Here is how send() is
specified :

"The length of the message to be sent is specified by the length
argument.

[...]

If the socket argument refers to a socket and the flags argument is 0,
the send() function is equivalent to write()."

And here is write() :

"If nbyte is zero and the file is not a regular file, the results are
unspecified."

We might also want to change this though, since the behaviour observed
on other systems seems more appropriate.

-- 
Richard Braun