Re: typeof and bitfields

[Paul Schlie <schlie at comcast dot net>]

> Gabriel Dos Reis wrote:
> | Mark Mitchell wrote:
> | There's only one good reason, and Matt has already given it: backwards
> | compatibility.  Fortunately, that compatibility is only with a GNU
> | extension used in a pretty obscure way, and there is an easy
> | workaround (don't use typeof; use the type of the bitfield instead)
> | that will work in most cases.
> 
> The advice "don't use typeof" does not make much sense.  Indeed,
> typeof is mostly used precisely when the type of the operand it not
> known, e.g. in macros.

Here's some interesting text from C which implies that an unnamed bit-field
may be specified with the syntax: [type-name]:size.

(which would seem to support the notion that: typedef unsigned:4 ubf_4
 could be validly interpreted as ubf_4 :: 4-bit unsigned bit-field type,
 and subsequently be used to declare a named object, and/or further
 qualified: i.e. const ubf_4 x :: const unsigned x:4, then by implication
 typeof(ubf_4) :: <unsigned:4_type>; and that sizeof returning the size
 of an addressable storage unit large enough to hold a bit-field would be
 a reasonable interpretation; if either were desired to be supported).

6.5.2  Type specifiers
6.5.2.1  Structure and union specifiers
...
 Semantics
 ...
       [#10] A bit-field declaration with no declarator, but only a
       colon and a width, indicates an unnamed bit-field.92   As  a
       special  case  of  this, a bit-field structure member with a

       [#9] An implementation may allocate any addressable  storage
       unit  large  enough  to  hold  a bit-field.  If enough space
       remains, a bit-field that immediately follows  another  bit-
       field  in  a structure shall be packed into adjacent bits of
       the same unit.  If insufficient  space  remains,  whether  a
       bit-field  that  does  not  fit is put into the next unit or
       overlaps  adjacent  units  is  implementation-defined.   The
       order  of allocation of bit-fields within a unit (high-order
       to low-order or low-order to high-order) is  implementation-
       defined.   The  alignment of the addressable storage unit is
       unspecified.

6.5.7  Type definitions
...
 Examples
 ...
         3.  The following obscure constructions

                     typedef signed int t;
                     typedef int plain;
                     struct tag {
                             unsigned t:4;
                             const t:5;
                             plain r:5;
                     };

             declare a typedef name  t  with  type  signed  int,  a
             typedef name plain with type int, and a structure with
             three bit-field members, one  named  t  that  contains
             values  in  the  range  [0,  15],  an  unnamed  const-
             qualified bit-field which (if it  could  be  accessed)
             would contain values in at least the range [-15, +15],
             and one named r that contains values in the range  [0,
             31]  or values in at least the range [-15, +15].  (The
             choice of range is implementation-defined.)  The first
             two  bit-field declarations differ in that unsigned is
             a type specifier (which forces t to be the name  of  a
             structure  member),  while  const  is a type qualifier
             (which modifies t which is still visible as a  typedef
             name).  If these declarations are followed in an inner
             scope by

                     t f(t (t));
                     long t;

             then a function f is  declared  with  type  ``function
             returning  signed  int with one unnamed parameter with
             type pointer to function returning signed int with one
             unnamed  parameter  with  type  signed  int'',  and an
             identifier t with type long.