Skip site navigation (1)Skip section navigation (2)
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>