From owner-freebsd-hackers@freebsd.org Sun Aug 2 03:49:47 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 21B569AF2CB for ; Sun, 2 Aug 2015 03:49:47 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EC6CBAED for ; Sun, 2 Aug 2015 03:49:46 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t723nktq081107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Aug 2015 20:49:46 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t723njF4081106; Sat, 1 Aug 2015 20:49:45 -0700 (PDT) (envelope-from jmg) Date: Sat, 1 Aug 2015 20:49:45 -0700 From: John-Mark Gurney To: Jordan Hubbard Cc: Patrick Mooney , "freebsd-hackers@freebsd.org" Subject: Re: Interpretation of POSIX.1-2008 for recvmsg Message-ID: <20150802034945.GN78154@funkthat.com> References: <20150802000945.GL78154@funkthat.com> <476D3B86-896E-4049-8006-ADF964C7ECC3@icloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <476D3B86-896E-4049-8006-ADF964C7ECC3@icloud.com> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Sat, 01 Aug 2015 20:49:46 -0700 (PDT) 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 03:49:47 -0000 Jordan Hubbard wrote this message on Sat, Aug 01, 2015 at 18:10 -0700: > One obvious approach might be to run Patrick's test case on a OS X system, since it's one of the very few remaining (still living) UNIX??? platforms that has to pass the official (and really large) Unix Conformance test suite. Whatever OS X's behavior is, arguably right or wrong, you'll at least know that TOG signed off on it. Ok, I know it's a bit old, but MacOSX 10.7.5: $./peektest peek len: 0 errno: 0 flags: 12 recv len: 20 errno: 0 flags: 0 and NetBSD 6.1.5: # ./peektest peek len: 0 errno: 0 flags: 12 recv len: 20 errno: 0 flags: 0 and OpenBSD 5.7: # ./peektest peek len: 0 errno: 0 flags: 12 recv len: 20 errno: 0 flags: 0 > > On Aug 1, 2015, at 17:09, John-Mark Gurney wrote: > > > > Patrick Mooney wrote this message on Fri, Jul 31, 2015 at 13:20 -0500: > >> I have been researching differences in recvmsg() behavior across platforms > >> (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 recvmsg() > >> call with a 0-length iovec and flags set to MSG_PEEK in order to interrogate > >> the size of a queued dgram. On native Linux, recvmsg() returns the size of 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. > > > > 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. > > > > 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... > > > > Feel free to ask the opengroup. They have forums to clarify unclear > > parts of the spec... > > > > 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... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."