bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andreas Cadhalpun
Subject: Re: Bug#752237: libc0.3: send() asked to transmit 0 chars still triggers recv() on Hurd
Date: Sat, 28 Jun 2014 19:12:16 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0

Hi Richard,

On 28.06.2014 10:48, Richard Braun wrote:
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.

Thanks for looking into this.
Indeed, according to the specification, the behavior is unspecified. (Which IMHO is a bug in the specification.)
But the specification also says:
"Before any action described below is taken, and if nbyte is zero and the file is a regular file, the write() function may detect and return errors as described below. In the absence of errors, or if error detection is not performed, the write() function shall return zero and have no other results."

This holds only for regular files, but the principle of least surprise suggests that it should also hold for special files, if that is possible.

On 28.06.2014 11:51, Richard Braun wrote:
> I've committed a fix upstream [1], please see if it solves your issues
> as well.

I tried this patch and with it applied both the example program and clamd/clamdscan work as they should.
But I can't comment on Samuel's objections to the patch.

Best regards,
Andreas



reply via email to

[Prev in Thread] Current Thread [Next in Thread]