On 9/2/19 10:51 PM, Rich Felker wrote:
> 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).

I'm also in favor of 'int' (but not the 'int32_t' proposal mentioned in
note 4538).  Does anyone volunteer to write up the glibc patch, while I
report back to the Austin Group that 'int' is the preferred type for
standardization?

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org