This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: f_owner_ex vs. POSIX
- From: Rich Felker <dalias at libc dot org>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: "Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>, Eric Blake <eblake at redhat dot com>, glibc list <libc-alpha at sourceware dot org>, linux-man at vger dot kernel dot org
- Date: Mon, 2 Sep 2019 23:51:32 -0400
- Subject: Re: f_owner_ex vs. POSIX
- References: <a6d65cee-a909-449c-484d-66cd26093958@redhat.com> <bdc9527b-6595-9f4e-b35d-3796967e044c@gmail.com> <87mufmvmlm.fsf@oldenburg2.str.redhat.com>
On Mon, Sep 02, 2019 at 03:44:53PM +0200, Florian Weimer wrote:
> * Michael Kerrisk:
>
> > I do not know what the rationale was for the addition of the 'enum',
> > and it wouldn't surprise me if there was no public discussion about
> > it. The use of an 'enum' strikes me as a slightly odd decision (given
> > that the kernel uses 'int') but, related to your point below, there
> > is precedent in, for example, the use of an 'enum' for 'idtype_t' in
> > waitid() inside glibc, while the kernel type for the argument in
> > the underlying system call is 'int'.
>
> There is also the issue of -fshort-enum. Some people probably expect
> that they can use that option and still use glibc headers.
>
> I do not have any inside knowledge why things are like they are.
> Presumably we can switch the type member to int.
I'm strongly in favor of switch to int. enum types are an
ABI/compatibility nightmare and have little purpose (unlike enum
constants which are actually useful).
Rich