On Mon, 21 Jan 2002, Richard Earnshaw wrote:

: It means that a better argument than has been presented so far (basically,
: bad programs might not work) to justify the loss of benefit to those
: people who need enums to use the minimal space (if they don't then they
: will be forced to not use enums).

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

: > 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)

* 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)

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.

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

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi & NetBSD:  Run with it.
-- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/