> At present, all NetBSD ports have fixed-size enumeration types, so all
> enums on a given port are the same size.  The forthcoming ARM EABI-2001 is
> very likely 

I would put the chances of it not being as batting around zero.

> to specify variable-length enumeration types, where enums have
> the same size as the smallest integer type that will contain all their
> enumarators.

> 
> Reasons why we should not use -fshort-enums:
>  * Enum membership changes cause ABI changes, and hence library major
>    number changes at unexpected times.

Can cause.  Will only affect enums that cross a size boundary, and only if 
the designers haven't thought about the issue in advance.  Even then, the 
most likely source of failure will be if the enum values are used in 
structures that are used in a visible public interface.

>  * Enums will tend to be types that are slow to load and store  on ARMv3,
>    which is our default compiler target.

Most enums that I've seen are in the range 0-255; very few will need more 
than this.

>  * Much third-party software assumes -fno-short-enums.
And is broken.

> My opinion is that we should actually keep our current ABI for enums.  I
> don't think that following ARM's ABI is particularly desirable, since on
> past experience it'll change at some point anyway (witness the
> struct-alignment business), but I'd like to hear what other people think.

While in the past the ARM ABI has been fluid this largely stems from the 
fact that nothing has been written down and published: the whole point of 
writing such a thing down and publishing it is that it should be 
stabilized for the future.

Personally, I think it would be a mistake to deviate in this area.

R.