Richard Earnshaw wrote:

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

So you mean it is 99% fixed....
> 
> > to specify variable-length enumeration types, where enums have
> > the same size as the smallest integer type that will contain all their
> > enumarators.

Does this allow enums outside [-2^31..2^31) ?
> 
> >
> > 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.

I don't think there are many enums visible in 'traditional' structures.
IMHO they aren't strongly typed enough to be useful.
> 
> >  * 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.

But doesn't the 'load signed byte' not appear until v4?  So even loads
near the start of structures will require 2 shifts to sign extend (or 1
to place at the top of the register).

Maybe there should be an option for the system build to use a later set?

Any maths (ok any comparisons after maths) require that the value be
truncated correctly.  This all generates code bloat.

The other problem (does it affect arm?) whether the top bits of
registers user to pass and return arguments / results to / from
functions are guaranteed to be correctly sign extended.

Having any integers that are not the true 'natural' size for the
architecture (32bits for almost everything except ILP64 alpha) costs
code.
> 
> >  * Much third-party software assumes -fno-short-enums.
> And is broken.

Much 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.

I'm not really in a position to give anything other than my personal
opinion (which, as usual, I'll give freely :-)  But if you want your
code to bloat you use 'short' and 'char' for simple variables, function
arguments, and function return values.  I've seen many cases where,
because the DOMAIN of an argument is 0..65535, it is defines as 'short'
rather than 'int' leading to code bloat.

Does gcc support 'enum' bit fields?
> 
> 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.

What is the ratinal behind picking varialbe sized enums?  After all most
choices these days are made on efficiency, not size basis.  (Isn't the
change to structure alignments - all 32 bit? instead of 'as required by
largest member' - one that gains a slight efficiency saving at the cost
of a small amount of space?)

I would have thought it would be more appropriate to change the other
way!
> 

On a related subject, do we use 16bit or 32bit wide characters?

	David