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] Fix prototype for eventfd


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.


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