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

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Geoffrey Keating <geoffk@geoffk.org> writes:

| Roger Sayle <roger@eyesopen.com> writes:
| 
| > Could one of GCC's resident C/C++ language lawyers confirm that the
| > behaviour of the following code is undefined?
| > 
| > 
| > extern "C" void abort(void);
| > 
| > enum E { e = 0x0f };
| > 
| > void test(int n)
| > {
| >   enum E x, y;
| > 
| >   x = (E)0x10;
| >   y = (E)n;
| > 
| >   if (x != y)
| >     abort ();
| > }
| > 
| > int main()
| > {
| >   test(0x10);
| >   return 0;
| > }
| > 
| > 
| > Normally, when storing a narrower mode within a wider one, GCC's RTL
| > supports one of three representations: zero extended, sign extended
| > and paradoxical.  I'd just like confirmation that C/C++ bitfields
| > are intended to use a paradoxical representation.
| 
| There aren't any bitfields in your example.

Not directly, but throught the specification 7.2/6

   For an enumeration where emin is the smallest enumerator and emax
   is the largest, the values of the enumeration are the values of the
   underlying type in the range bmin to bmax, where bmin and bmax are,
   respectively, the smallest and largest values of the smallest
   bit-field that can store emin and emax.81) It is possible to define
   an enumeration that has values not defined by any of its
   enumerators. 

-- Gaby