This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Fix prototype for eventfd
- From: Rasmus Villemoes <rv at rasmusvillemoes dot dk>
- To: libc-alpha at sourceware dot org
- Date: Mon, 19 May 2014 14:48:27 +0200
- Subject: Re: [PATCH] Fix prototype for eventfd
- Authentication-results: sourceware.org; auth=none
- References: <8761lraz3r dot fsf at rasmusvillemoes dot dk> <87a9asifl0 dot fsf at rasmusvillemoes dot dk> <20140513200012 dot GB15468 at domone dot podge> <Pine dot LNX dot 4 dot 64 dot 1405132026260 dot 30034 at digraph dot polyomino dot org dot uk> <20140516142404 dot GB29829 at domone dot podge>
OndÅej BÃlka <neleai@seznam.cz> writes:
> On Tue, May 13, 2014 at 08:33:58PM +0000, Joseph S. Myers wrote:
>> On Tue, 13 May 2014, Ondrej Bilka wrote:
>>
>> > On Thu, May 08, 2014 at 03:07:39PM +0200, Rasmus Villemoes wrote:
>> > > Rasmus Villemoes <rv@rasmusvillemoes.dk> writes:
>> > >
>> > > > Both the man-page and the actual kernel source says that the first
>> > > > argument to eventfd is unsigned int, not simply int.
>> > > >
>> > >
>> > > ping
>> >
>> > looks good, I am bit concerned with compatibility, Joseph could you also
>> > comment it?
>>
>> Compatibility would be an issue if:
>>
>> * the C ABI on some architecture defines int to be sign-extended to 64
>> bits when passed as a function parameter, but unsigned int to be
>> zero-extended;
>>
>> * the code generated for eventfd relied on this in some way; and
>>
>> * a user binary passes a negative value for the int argument.
>>
>> I don't expect that to be an issue (in that I don't expect any dependence
>> beyond the value passed to the function being passed on to the kernel
>> unchanged) but haven't looked at generated code.
>>
> I looked linux fs/eventfd.c and it should not be case as a parameter is
> passed to different function. OK to commit patch with this changelog?
Fine by me.