This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v2][BZ 16852] Do not clobber recvmmsg argument.


On Wed, Apr 30, 2014 at 6:04 PM, Rich Felker <dalias@libc.org> wrote:
> On Wed, Apr 30, 2014 at 03:35:40PM +0200, Michael Kerrisk (man-pages) wrote:
>> On Wed, Apr 30, 2014 at 1:17 PM, Michael Kerrisk (man-pages)
>> <mtk.manpages@gmail.com> wrote:
>> > Hello OndÅej,
>> >
>> > On 04/30/2014 11:07 AM, OndÅej BÃlka wrote:
>> >> On Wed, Apr 30, 2014 at 10:28:53AM +0200, Michael Kerrisk (man-pages) wrote:
>> >>> On 04/28/2014 07:01 PM, David Miller wrote:
>> >>>> From: OndÅej BÃlka <neleai@seznam.cz>
>> >>>> Date: Mon, 28 Apr 2014 18:04:20 +0200
>> >>>>
>> >>>>>    * sysdeps/unix/sysv/linux/recvmmsg.c (recvmmsg): Do not clobber
>> >>>>>    timeout argument.
>> >>>>
>> >>>> It is extremely unfortunate if we've defined this argument as const,
>> >>>> now you are making it so that the user has no mechanism to get the
>> >>>> updated timeval other than to define their own syscall stubs.
>> >>>>
>> >>>> This is doubly unfortunately since there is absolutely no reason for
>> >>>> us to have defined the interface different from what the kernel
>> >>>> actually provides.
>> >>>
>> >>> Agreed. Surely, the right fix here is simply to remove the "const"
>> >>> qualifier from the glibc API?
>> >>>
>> >> Now I am also for removing const. Initially I looked to documentation
>> >> and this was undocumented feature so I was not sure about it.
>> >
>> > Yes, my mistake.
>>
>> Sigh! Now I remember why that timeout behavior didn't get documented:
>>
>> http://thread.gmane.org/gmane.linux.man/3477/focus=3500
>>
>> The timeout argument is completely broken, AFAICT. I never did get a
>> reply from Arnaldo (but, as you can see in the thread, others agreed
>> tha there's a problem), and then I got distracted :-{.
>
> Indeed, this looks like a big problem and I don't see any viable
> solution. I think the documented behavior, for now, should be that the
> behavior is unspecified unless the timeout is a null pointer.

I got the formulation of the program slightly wrong, but the
fundamental problem is the same:

http://thread.gmane.org/gmane.linux.man/5677/focus=5702

Cheers,

Michael



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]