This is the mail archive of the
libc-alpha@sourceware.org
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
- Cc: Rich Felker <dalias at libc dot org>, "Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>
- Date: Mon, 2 May 2016 16:17:05 -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> <20160421171459 dot GA23969 at brightrain dot aerifal dot cx>
On 21/04/2016 14:14, Rich Felker wrote:
> On Mon, Mar 28, 2016 at 11:34:00AM -0300, Adhemerval Zanella wrote:
>> POSIX specifies that both msghdr::msg_iovlen and msghdr::msg_controllen
>> to be of size int and socklen_t respectively. However Linux defines it as
>> both size_t and for 64-bit it requires some adjustments to make the
>> functions standard compliance.
>>
>> This patch fixes it by creating a temporary header and zeroing the pad
>> fields for 64-bits architecture where size of size_t exceeds the size of
>> the int.
>>
>> Also the new recvmsg and sendmsg implementation is only added on libc,
>> with libpthread only containing a compat symbol.
>
> Just a heads-up: this needs a bug report/patch to the Linux man-pages
> project as well, since they're currently documenting the wrong types.
> The documented types should probably be fixed to align with the
> standard, with a note about them previously being wrong added to the
> NOTES section.
>
> Rich
>
Based on previous messages I think Michael Kerrisk is already taking care
of it.
I think the remaining issue regarding this patch is 1. the alignment
issue for cmsg_hdr and 2. the sendmsg cmsg padding.
For 1. I do not think this should be a block issue, so I would like
ask if someone have a impending reason for this patch.
For 2. I already have prepared patch that I intend to send after
this fix is upstream.