Interpretation of POSIX.1-2008 for recvmsg

John-Mark Gurney jmg at funkthat.com
Sun Aug 2 00:09:46 UTC 2015


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."


More information about the freebsd-hackers mailing list