Subject: Re: rpcgen and -fshort-enums round 2
To: Christos Zoulas <email@example.com>
From: Todd Vierling <firstname.lastname@example.org>
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 <email@example.com> * Wasabi & NetBSD: Run with it.
-- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/