Subject: Re: emuns on ARM: What should we do?
To: Ben Harris <firstname.lastname@example.org>
From: Richard Earnshaw <email@example.com>
Date: 01/19/2002 15:06:05
> 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
> 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
> * 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.