Subject: Re: rpcgen fix for -fshort-enums
To: Todd Vierling <firstname.lastname@example.org>
From: Richard Earnshaw <email@example.com>
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.