Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751084AbaBKKQq (ORCPT ); Tue, 11 Feb 2014 05:16:46 -0500 Received: from mail-pa0-f46.google.com ([209.85.220.46]:48907 "EHLO mail-pa0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750758AbaBKKQj convert rfc822-to-8bit (ORCPT ); Tue, 11 Feb 2014 05:16:39 -0500 MIME-Version: 1.0 Reply-To: mtk.manpages@gmail.com In-Reply-To: References: From: "Michael Kerrisk (man-pages)" Date: Tue, 11 Feb 2014 11:16:19 +0100 Message-ID: Subject: Re: recv function bug To: =?Big5?B?pbyo97Bfqrqu9g==?= Cc: linux-kernel , linux-man Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello ?????_????, On Sat, Feb 8, 2014 at 5:32 PM, ?????_???? wrote: > It is my pleasure to write here for you. > I have read 'Linux Programmer??s Manual RECV(2)'. The description of > return value is like this: These calls return the number of bytes received, > or -1 if an error occurred. The return value will be 0 when the peer has > performed an orderly shutdown. > Notice the bold text. It means that if the "recv" function return 0, the > connection has already been broken gracefully. But in the fallowing code, it > is not the case: > char buf[256]; > ssize_t rc; > size_t buflen = 0; > rc = recv( sockfd, buf, buflen, 0 ); // the 'rc' will be 0, but > the connection is still established > If the value of 'buflen' is 0, the "recv" function also return 0. But the > connection is still established. In another case, before the "recv" being > called, the remote programe close the socket (it means that the connection > has been broken), and the "recv" return 0 too. > SERVER > CLIENT > char buf[256]; > ssize_t rc; > size_t buflen = 0; > ...... > > close( sockfd ); > // before call recv, the connection has been broken gracefully > ...... > rc = recv( sockfd, buf, buflen, 0 ); // the 'rc' will be 0, but > the connection is broken > > So, when I call the "recv" function with the value 0 in the 3rd > argument, I'm not sure whether the connection is still OK by the return > value. > I think there is a conflict between the definition of the 3rd argument > and the return value. Thanks for this report. Yes, there are several details missing there. I've applied the patch below. Cheers, Michael --- a/man2/recv.2 +++ b/man2/recv.2 @@ -403,8 +403,16 @@ if an error occurred. In the event of an error, .I errno is set to indicate the error. -The return value will be 0 when the -peer has performed an orderly shutdown. + +When a stream socket peer has performed an orderly shutdown, +the return value will be 0 (the traditional "end-of-file" return). + +Datagram sockets in various domains (e.g., the UNIX and Internet domains) +permit zero-length datagrams. +When such a datagram is received, the return value is 0. + +The value 0 may also be returned if the requested number of bytes +to receive from a stream socket was 0. .SH ERRORS These are some standard errors generated by the socket layer. Additional errors -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/