This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 2/3] network: recvmsg and sendmsg standard compliance (BZ#16919)
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: libc-alpha at sourceware dot org
- Date: Thu, 7 Apr 2016 09:29:17 -0300
- Subject: Re: [PATCH 2/3] network: recvmsg and sendmsg standard compliance (BZ#16919)
- Authentication-results: sourceware.org; auth=none
- References: <1459175641-12520-1-git-send-email-adhemerval dot zanella at linaro dot org> <1459175641-12520-3-git-send-email-adhemerval dot zanella at linaro dot org> <57062EC6 dot 20504 at redhat dot com> <57064679 dot 5000405 at arm dot com>
On 07-04-2016 08:37, Szabolcs Nagy wrote:
> On 07/04/16 10:56, Florian Weimer wrote:
>> On 03/28/2016 04:34 PM, Adhemerval Zanella wrote:
>>> diff --git a/sysdeps/unix/sysv/linux/check_native.c b/sysdeps/unix/sysv/linux/check_native.c
>>> index b3cbbe3..a8e447e 100644
>>> --- a/sysdeps/unix/sysv/linux/check_native.c
>>> +++ b/sysdeps/unix/sysv/linux/check_native.c
>>> @@ -111,10 +111,13 @@ __check_native (uint32_t a1_index, int *a1_native,
>>> struct msghdr msg =
>>> - (void *) &nladdr, sizeof (nladdr),
>>> - &iov, 1,
>>> - NULL, 0,
>>> - 0
>>> + .msg_name = (void *) &nladdr,
>>> + .msg_namelen = sizeof (nladdr),
>>> + .msg_iov = &iov,
>>> + .msg_iovlen = 1,
>>> + .msg_control = NULL,
>>> + .msg_controllen = 0,
>>> + .msg_flags = 0
>> The requirement for such changes always makes me nervous. If we have
>> breakage in our own code, how many applications are affected?
> yes, it looks risky.
>> Note that the recvmsg manual page says “is defined as follows” about
>> struct msghdr, not “contains the following members in some arbitrary order”.
> i think the man page should be more clear about
> that the msg_controllen, msg_iovlen and cmsg_len
> types conflict with posix.
> to prevent more non-portable code being written
> based on the linux man page.
>> Is standards compliance here really worth this risk?
>> (I do not have a strong opinion either way, I just want to raise this
I do not have a strong opinion as well, but I also do not see it a
compelling reason to *not* follow the standard as well. I would follow
Szabolcs suggestion and update the manual specifying to more portable
way to access the structures is through designated initializers (which
gcc accepts in c90 as well).
Best option would be to get this fixed in kernel, but it is another