[PATCH 2/3] network: recvmsg and sendmsg standard compliance (BZ#16919)

[Adhemerval Zanella]

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
>> point.)
>>
>> Florian
>>
> 

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