Fix prototype for eventfd
Commit Message
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?
2014-05-16 Rasmus Villemoes <rv@rasmusvillemoes.dk>
* ports/sysdeps/unix/sysv/linux/hppa/sys/eventfd.h (eventfd):
Make first argument unsigned.
* sysdeps/unix/sysv/linux/eventfd.c (eventfd): Likewise.
* sysdeps/unix/sysv/linux/sys/eventfd.h (eventfd): Likewise.
Comments
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.
b/ports/sysdeps/unix/sysv/linux/hppa/sys/eventfd.h
@@ -40,7 +40,7 @@ __BEGIN_DECLS
/* Return file descriptor for generic event channel. Set initial
value to COUNT. */
-extern int eventfd (int __count, int __flags) __THROW;
+extern int eventfd (unsigned int __count, int __flags) __THROW;
/* Read event counter and possibly wait for events. */
extern int eventfd_read (int __fd, eventfd_t *__value);
b/sysdeps/unix/sysv/linux/eventfd.c
@@ -22,7 +22,7 @@
int
-eventfd (int count, int flags)
+eventfd (unsigned int count, int flags)
{
#ifdef __NR_eventfd2
int res = INLINE_SYSCALL (eventfd2, 2, count, flags);
b/sysdeps/unix/sysv/linux/sys/eventfd.h
@@ -31,7 +31,7 @@ __BEGIN_DECLS
/* Return file descriptor for generic event channel. Set initial
value to COUNT. */
-extern int eventfd (int __count, int __flags) __THROW;
+extern int eventfd (unsigned int __count, int __flags) __THROW;
/* Read event counter and possibly wait for events. */
extern int eventfd_read (int __fd, eventfd_t *__value);