Subject: Re: rpcgen and -fshort-enums round 2
To: Christos Zoulas <>
From: Todd Vierling <>
List: tech-toolchain
Date: 02/19/2002 05:21:56
On Tue, 19 Feb 2002, Christos Zoulas wrote:

: >People suggested that hardcoding 0x7fffffff into rpcgen's output was ugly,
: >so how about this?  Note that the rpcgen changes are complicated by having
: >to undo one of christos' fixes, and I'm not entirely sure that my defines
: >either have the right names or are in the right place.  I'll commit this
: >if no-one comes up with a better idea by Saturday though.
: I don't understand why we need fixed size enums in the api, since rpcgen
: will generate code that converts back and forth to ints...

bjh noted, in an earlier thread, that rpcgen generates code that casts "enum
foo *" to "enum_t *" -- something that will break without these "size
forcing" constants.  (Think of an 8-bit enum:  On little endian ARM, you get
24 bits of junk.  On an as-yet unavailable big-endian ARM, you'd get an enum
shifted 24 bits.)

-- Todd Vierling <>  *  Wasabi & NetBSD:  Run with it.
-- CDs, Integration, Embedding, Support --