RE: Help with bit-field semantics in C and C++

["Steven L. Zook" <SLZook at Qualstar dot com>]

Ok, it sounds like I wasn't tracking the discussion quite right (which is what I was trying to ascertain). By "enumeration value" it sounds like what you mean is a numerical representation that fits in the minimum bit width of the type (in my example case 4 bits in width and so any of 16 values would qualify, thus a masking operation can always bring any integer value into range). 

The interpretation I had mistakenly come to was one of the specified enumeration values (in my example One, Two, Four, or Eight). This mistake was helped by the fact that all of the examples in the discussion were "packed" (that is all possible values in the "enumeration value" were explicitly declared, e.g. enum eOneBit { Zero, One }).

I will leave quietly now and go back to lurking mode.

Thanks

-----Original Message-----
From: gdr@integrable-solutions.net [mailto:gdr@integrable-solutions.net]
Sent: Friday, August 27, 2004 3:01 PM
To: Steven L. Zook
Cc: GCC Mailing List (E-mail)
Subject: Re: Help with bit-field semantics in C and C++


"Steven L. Zook" <SLZook@Qualstar.com> writes:

| Another interesting case:
| 
| enum eSparse { One = 1, Two = 2, Four = 4, Eight = 8 };
| eSpare Sparse;
| 
| The current compilers would place Sparse in .bss and it will end up
| initialized to 0. 

Which is OK -- 0 is an enumeration value of eSparse.

| If the compiler is to ensure that the variable is
| in-range, does that require it to be constructed/initialized and
| thus should be in .data? 

I assume you put the above at global scope.  Therefore it is
value-initialized to the correct thing.  Why do you see that different
from

   signed char i;

and i being initialized to 0?

-- Gaby