> 
> Perhaps a counterargument:  ARM's need for alignment of data completely
> obviates the gain by -fshort-enums.  Only platforms that can load any size
> data on any boundary (read: i386 or similar) can truly gain space in the
> general case using short enums.
> 
> On an aligned platform, code must be *designed* to use it -- that is, with
> full knowledge of all the possible values of an enum, and thus the enum's
> size, so that struct members can be reordered to fill in the alignment.
> Otherwise you'll end up with cases like:
> 
> struct foo {
>     enum bar a;
>     int b;
>     enum baz b;
> };
> 
> This arrangement of struct, rather common at that, gains squat when it comes
> to -fshort-enums.  Given that bar and baz have <256 values, there's three
> bytes wasted after `a' for alignment of the following int, and three bytes
> wasted after `b'.
> 
> Now, you still waste the space without -fshort-enums.  However, you don't
> gain future ABI incompatibility, as the space is available to expand the
> enum (as it has been for most other architectures out there using C).

But this is still an argument along the lines that lack of thought for 
those that don't care should win over the benefits for those that do.

For someone who does care about space savings, the above structure would 
be written as

struct foo {
    enum bar a;
    enum baz c;
    int b;
};

Which would then save upto 33% of memory.  

You are trying to suggest that nobody thinks about the impact of structure 
layout.  This is simply untrue.

> : > I don't think there are many enums visible in 'traditional' structures.
> : > IMHO they aren't strongly typed enough to be useful.
> :
> : Indeed, I very much doubt that such a selection of packed enums is going
> : to lead to regular bumping of shared lib numbers as has been claimed.
> 
> This will adversely impact:
> 
> * big-endian ARM (because ABI incompatibilities are masked on little-endian
>   systems by virtue of the fact that the LSB is first in a 4-byte int)

No, it just means that the bug is likely to show itself earlier (one could 
regard that as a good thing).

> * any uninitialized memory for a struct that is initialized by element (the
>   extra bytes may get random data in code that assumes a shorter enum size)

so... anyone comparing structures with memcmp or equivalent should be shot!

> It also introduces additional code overhead for masking and shifting the
> bits of a short enum on a load/store.
> 
> If space is such an issue, then -fshort-enums is not your answer.  That's
> simply asking the compiler to make assumptions about your code that don't
> help *general code* on a system that requires type alignment.
> 
> If code *really* needs a space gain, it should be using bit-sized types and
> not relying on a compiler hack.  If code is designed to save space, it
> should be designed to know *exactly* how large its data is.

Bit-sized enums are not portable.

> So, I still don't see the gain by making -fshort-enums a default.  But I see
> definite compatibility issues with existing code.

Anyone who really wanted to ensure portability of an interface that might 
change over time would simply add a place-holder enum that forced the type.

Eg

enum mine { a, b, c, d, dummy=UINT_MAX};

Such an enum would then always take the same amount of space even if more 
values were added at a later date.  You are simply trying to argue that 
laziness should have a greater precedence than forethought.

R.