Date: Sat, 01 Aug 2015 18:10:24 -0700 From: Jordan Hubbard <jordanhubbard@icloud.com> To: John-Mark Gurney <jmg@funkthat.com> Cc: Patrick Mooney <patrick.mooney@joyent.com>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Interpretation of POSIX.1-2008 for recvmsg Message-ID: <476D3B86-896E-4049-8006-ADF964C7ECC3@icloud.com> In-Reply-To: <20150802000945.GL78154@funkthat.com> References: <CABtm=mocvtBO46PDR7SPokOr57z_DphOu5rKZPk7ATjweL_Awg@mail.gmail.com> <20150802000945.GL78154@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jmg@funkthat.com> 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"=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?476D3B86-896E-4049-8006-ADF964C7ECC3>