Subject: Re: rpcgen fix for -fshort-enums
To: None <tech-toolchain@netbsd.org>
From: Christos Zoulas <christos@zoulas.com>
List: tech-toolchain
Date: 02/05/2002 17:21:04
In article <Pine.WNT.4.43.0202051126350.1112-100000@todd>,
Todd Vierling <tv@wasabisystems.com> wrote:
>
>-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.

But this has always been left open in the C standard. Enum types,
not unlike structures and unions introduce distinct types in the
type system that are not mutually assignable, or need to have the
same size.  I.e. there was never a guarantee in c that sizeof(enum
a) == sizeof(enum b). That is why rpc_types.h defines enum_t to be
int32_t, to avoid this ambiguity.

Fortunately not much code makes this assumption (that enums are
fixed size), unlike the sizeof(long) == sizeof(int) fiasco a decade
ago, that even today keeps biting.

christos