tOn Tue, 5 Feb 2002, Richard Earnshaw wrote:

: > The revisions you site are simple fixed-size type fixups.  They aren't on
: > the scale of hackery required to work around the -fshort-enums braindamage.
:
: Oh come on.  Grow up.  -fshort-enums is a perfectly legitimate
: implementation of enums, just like using 64-bits for a long is perfectly
: legitimate.  If code isn't written portably then it's going to have to be
: fixed when it is ported.  That's a fact of life.  You can't define the
: problem away by just pretending it isn't there.

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.

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.

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