Re: Fun with C

[David Thompson <dave.thompson2@verizon.net>]

On Thu, 28 Apr 2011 09:41:57 -0400, Hyman Rosen <hyrosen@mail.com>
wrote:

> On 4/28/2011 1:13 AM, David Thompson wrote:
> > On Thu, 21 Apr 2011 15:27:40 -0400, Hyman Rosen<hyrosen@mail.com>
> > wrote:
> >> That doesn't work for C because a variable of an enum type
> >> may hold any integer value up to the number of bits taken
> >> by the largest enumerator (with a variation for negatives
> >> that isn't important here). The C enum concept is meant to
> >> encompass literals used as bit masks as well as singular
> >> values.
> >
> > s/up to/up to at least/
> 
> C++ restricts the permitted values, as per 7.2/6: <snip>

C++ kinda does; C doesn't. 

C++ makes each enum type a distinct type _implemented_ as some
'underlying' integral type with the additional constraint you quoted,
plus restriction on conversion, and ability to overload. Trying to
convert a value outside that range is 'unspecified' which means an
implementation can use whatever it wants, and needn't document or
diagnose; every C++ implementation I've seen just uses the
out-of-range value up to the range of the underlying type, which gives
the same effect as C although not officially guaranteed.

C makes an enum type _be_ an integer type, with all the properties
including value range of that type. To be exact it says  'compatible',
and some other places in C 'compatible' is weaker than identity, but
for enum there I see no detectable difference. A C99 implementation
can have extended integer types, which could cover all bit widths, but
usually it provides, and uses for enums, only a few. In fact in C 
it is easy and common for the compiler to just use type 'int' for all
enum types. (In C enums can't exceed int, so this is always safe,
though not always optimal; in C++ they can, but the underlying type
can exceed int only if necessary. Of course on many machines nowadays
int and long are the same size anyway, and C++1X with long long hasn't
been approved yet last I looked.)