Simon, Paul,
> > Android users are constantly worrying about whether to compile
> > with -fno-short-enums, citing ABI incompatibilities. E.g., see
> > <http://osdir.com/ml/android-ndk/2010-10/msg00559.html>.
>
> Thanks for this information. I feared that the old assumption "enum =
> int" that I have relied on wasn't really true.
But you need to distinguish the enum type and way its passed in function
parameters and return values.
1) About the enum *type*: Certainly an array
extern enum foo my_array[10];
will have a different size when you compile with -fshort-enums vs.
-fno-short-enums.
2) About the parameter passing convention:
ISO C 99 section 6.7.2.2.(3) says:
"The identifiers in an enumerator list are declared as constants
that have type int"
ISO C 99 section 6.7.2.2.(4) says:
"Each enumerated type shall be compatible with char, a signed
integer type, or an unsigned integer type. The choice of type is
implementation-defined, but shall be capable of representing the
values of all the members of the enumeration."
The term "Compatible types" is explained in section 6.2.7.
Although said citation would allow
sizeof (enum foo) > sizeof (int)
it would be stupid for a compiler vendor to do this. I think, in
practice you can assume that sizeof (enum foo) <= sizeof (int).
Which means, an enum is passed in one memory word or one register.
I would assume that the "usual arithmetic conversions" also apply
to enum types, meaning that even if an enum type if compatible to 'short',
a value of 7 will be passed as 0x00000007 and not as 0xDE820007.
Therefore I don't think you have a high risk of breaking the ABI
on any platform with at least 32-bit words by changing the parameter
or return type of a function from 'enum foo' to 'int' or vice versa.
Things might be different on platforms where an 'int' occupies
two memory words (16-bit and 8-bit CPUs), but these are surely not
among your targets.
Bruno
--
In memoriam Eduard Brücklmeier <http://en.wikipedia.org/wiki/Eduard_Brücklmeier>
