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

[Adhemerval Zanella]

On 21-04-2016 11:01, Szabolcs Nagy wrote:
> On 28/03/16 15:34, Adhemerval Zanella wrote:
>>  /* Structure used for storage of ancillary data object information.  */
>>  struct cmsghdr
>>    {
>> -    size_t cmsg_len;		/* Length of data in cmsg_data plus length
>> -				   of cmsghdr structure.
>> -				   !! The type should be socklen_t but the
>> -				   definition of the kernel is incompatible
>> -				   with this.  */
>> +#if __BYTE_ORDER == __BIG_ENDIAN
>> +    int __glibc_reserved1;	/* Pad toadjust Linux size to POSIX defined
>> +				   size for cmsg_len.  */
>> +    socklen_t cmsg_len;		/* Length of data in cmsg_data plus length
>> +				   of cmsghdr structure.  */
>> +#else
>> +    socklen_t cmsg_len;
>> +    int __glibc_reserved1;
>> +#endif
>>      int cmsg_level;		/* Originating protocol.  */
>>      int cmsg_type;		/* Protocol specific type.  */
> 
> i think #if __WORDSIZE == 64 is missing here.
> 

Right, I will add it.

> but even in that case there is a subtle issue:
> if the size_t member is removed all other
> members have 4byte alignment, so the struct
> alignment changes from 8byte to 4byte.
> 
> it is not clear from the standard how the
> msg_control buffer may be allocated (since
> only CMSG_* macros can access it), on linux
> the kernel makes a copy so it does not care
> about alignment in user-space, but the struct
> alignment is still visible in the c and c++ abi.

Indeed and I am not sure how to enforce (and if it is really required) in
the cleanest way. Do you think this as an blocker for such fix?

I am asking because I am following the mips64 ip thread failure report
for musl and looks like it is not really related to the change of 
struct alignment. Also I am testing on s390x and looks like both
make check and ip shows no issue. 

> 
> msg_control usage should be probably documented
> in the linux man-page: glibc sunrpc sometimes
> uses plain char[], nscd uses a union with struct
> cmsghdr, i think neither of them makes a
> 
>   CMSG_FIRSTHDR (&msg)->cmsg_len
> 
> access strictly iso c confrom, but the later at
> least uses correct alignment.
> 
> maybe a posix issue should be filed to the
> austin group.
>