From owner-freebsd-hackers  Thu Oct 17 04:24:23 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id EAA25005
          for hackers-outgoing; Thu, 17 Oct 1996 04:24:23 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA24994;
          Thu, 17 Oct 1996 04:24:09 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id VAA25414; Thu, 17 Oct 1996 21:18:59 +1000
Date: Thu, 17 Oct 1996 21:18:59 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199610171118.VAA25414@godzilla.zeta.org.au>
To: amcrae@cisco.com, hackers@FreeBSD.org, phk@FreeBSD.org
Subject: Re: enum considered bad ?
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

>I use enums where I can, and they are encouraged here at cisco.
>I prefer them because the compiler can be a little stricter
>with type checking and switch warnings etc., but it is
>surprising how many times you want to store those numbers
>in a char (so you can't declare the variable as an enum) or
>get at them in an assembler routiner.

gcc's __attribute__(()) works right in some cases, but not here:

	enum foo { ONE, TWO } __attribute__((__mode__(__QI__)));

tells you that __attribute__(()) doesn't apply to types.

	enum foo xxx __attribute__((__mode__(__QI__)));

gives an ordinary enum.

	enum foo xxx __attribute__((__mode__(__DI__)));

gives a long long enum.

I often store enums in char variables and interpret the
char variables in debuggers by casting back to enums.

Bruce