This is the mail archive of the
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: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
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).