From owner-freebsd-hackers@freebsd.org Sun Aug 2 01:10:49 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E781F9A546A for ; Sun, 2 Aug 2015 01:10:48 +0000 (UTC) (envelope-from jordanhubbard@icloud.com) Received: from nk11p03mm-asmtp002.mac.com (nk11p03mm-asmtpout002.mac.com [17.158.232.237]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D165CD3 for ; Sun, 2 Aug 2015 01:10:48 +0000 (UTC) (envelope-from jordanhubbard@icloud.com) Received: from [10.20.30.64] (75-101-82-48.static.sonic.net [75.101.82.48]) by nk11p03mm-asmtp002.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NSF00K6ZKLDOU00@nk11p03mm-asmtp002.mac.com> for freebsd-hackers@freebsd.org; Sun, 02 Aug 2015 01:10:28 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-08-01_02:2015-07-31,2015-08-01,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1508020018 References: <20150802000945.GL78154@funkthat.com> In-reply-to: <20150802000945.GL78154@funkthat.com> MIME-version: 1.0 (1.0) Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=utf-8 Message-id: <476D3B86-896E-4049-8006-ADF964C7ECC3@icloud.com> Cc: Patrick Mooney , "freebsd-hackers@freebsd.org" X-Mailer: iPad Mail (12H143) From: Jordan Hubbard Subject: Re: Interpretation of POSIX.1-2008 for recvmsg Date: Sat, 01 Aug 2015 18:10:24 -0700 To: John-Mark Gurney X-Mailman-Approved-At: Sun, 02 Aug 2015 01:42:49 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2015 01:10:49 -0000 One obvious approach might be to run Patrick's test case on a OS X system, s= ince it's one of the very few remaining (still living) UNIX=E2=84=A2 platfor= ms that has to pass the official (and really large) Unix Conformance test su= ite. Whatever OS X's behavior is, arguably right or wrong, you'll at least k= now that TOG signed off on it. - Jordan=20 Sent from my iPad > On Aug 1, 2015, at 17:09, John-Mark Gurney wrote: >=20 > Patrick Mooney wrote this message on Fri, Jul 31, 2015 at 13:20 -0500: >> I have been researching differences in recvmsg() behavior across platform= s >> (namely Illumos and Linux) with respect to MSG_PEEK and 0-length buffers.= >> Certain Linux software I am attempting to run under Illumos makes a recvm= sg() >> call with a 0-length iovec and flags set to MSG_PEEK in order to interrog= ate >> the size of a queued dgram. On native Linux, recvmsg() returns the size o= f the >> queued dgram (with the MSG_TRUNC flag set). On both Illumos and FreeBSD,= a >> size of 0 is returned (with MSG_TRUNC set as well). In reading the POSIX= spec >> (http://pubs.opengroup.org/onlinepubs/9699919799/functions/recvmsg.html),= it is >> not clear that returning 0 in this case is correct behavior. >=20 > I agree... These two statements conflict with each other in this case: > The recvmsg() function shall return the total length of the message. > For message-based sockets, such as SOCK_DGRAM and SOCK_SEQPACKET, the > entire message shall be read in a single operation. >=20 > If you can't read an entire message (since MSG_PEEK is set, and we can't > discard the bytes) per second statement, and excess bytes are not allowed > to be discard per next sentence, returning zero seems correct, since you > aren't reading a message... Though the return values and errno list > doesn't specify this type of return... >=20 > Feel free to ask the opengroup. They have forums to clarify unclear > parts of the spec... >=20 > Probing to find out how large a message is is bad programming practice.. > You should choose a buffer that is large enough for most messages, > and increase when it doesn't work... If you do this every time, you're > now doing 2x syscalls which will have performance/battery life impacts > as you're doing more work than is necessary... >=20 > --=20 > John-Mark Gurney Voice: +1 415 225 5579 >=20 > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"=