Subject: Re: rpcgen fix for -fshort-enums
To: Todd Vierling <>
From: Richard Earnshaw <>
List: tech-toolchain
Date: 02/05/2002 16:45:46
> rpcgen assumed that enums are a fixed size on any given platform, which has
> been correct for a very long time, even longer than "int" has been 32 bits
> on modern systems.  rpc/types.h defined an "enum_t" to be the size of an
> enum on the given target platform for precisely the purpose of representing
> "an enum".
> -fshort-enums introduces ambiguity in the size of enum types.  There's no
> more assurance on the size of an enum type remaining unchanged from one
> revision of the code to the next, and you can't have any definitive
> container value house "an enum" as has been done in many bits of code,
> including rpcgen.
> I don't see how you can so quickly ignore the problems -fshort-enums
> introduces, for a marginal bit of memory space gain.  I still haven't heard
> back from you on why using bit-sized types *instead of enums* for more
> compact struct representation is unacceptable.

No, there's a fundamental flaw in this line of thinking.  That is, that 
there is a single type called an enum.  Each enum is a distinct type, just 
as each struct or union is a distinct type.  You wouldn't, for example, 
expect to be able to cast a pointer to one structure to a pointer to any 
other structure and get portable code; and the same applies to enums.

Just because existing code assumes this does NOT mean that it is correct.

> As stated before, -fshort-enums really only helps the sloppy programmer (who
> doesn't lay out memory beforehand in a compact way using explicitly sized
> types).  And sloppy programmers don't give a damn about these kinds of space
> optimizations, either.  So the only people who will really notice the change
> of -fshort-enums in the long run are those who get *broken* by it.

You've got this completely backwards.  It's the sloppy programmers who've 
made the assumption that enums are of a fixed size.


PS.  We can continue this discussion until the cows come home.  It is 
*not* going to change the ARM EABI on this issue: that's not an item I 
could change, even if I wanted to.