>  > If my memory is correct, all types except "(signed) int" and "unsigned int"
>  > for bitfield are prohibited by ANSI.  And you should not expect the size or
>  > alignment of whole bitfields.  This is why bitfield should not used in
>  > protool header.
> 
> If this is the case, then there is a fair bit of code in NetBSD, especially
> older device drivers, which needs to be fixed to be strict about this.
> 
> In any case, GCC clearly supports it, because my Buslogic card works :-)

Since it is the restriction of ANSI C, we can go with GCC extensions.
Actually it is used for declaration of ip header in "/sys/netinet/ip.h",
and very commonly used in various *BSD, except FreeBSD, for years.

FYI, my MIPS ANSI C compiler warns:

cfe: Warning 658: bitfield2.c, line 5: bit-field 'bar' type required to be int, unsigned int, or signed int. (3.5.2.1(30))
        u_int8_t        bar:1,
        --------        ^
cfe: Warning 658: bitfield2.c, line 6: bit-field 'baz' type required to be int, unsigned int, or signed int. (3.5.2.1(30))
                        baz:5,
                        ^
cfe: Warning 658: bitfield2.c, line 7: bit-field 'zap' type required to be int, unsigned int, or signed int. (3.5.2.1(30))
                        zap:2;
                        ^
Anyway the alignment of whole bitfield depends on the implementation of
compiler.  For example, GCC has some configuration parameters, such as:
  /* Writing `int' for a bitfield forces int alignment for the structure.  */
  #define PCC_BITFIELD_TYPE_MATTERS 1
The parameter itself does not affect to bitfield with "u_int8_t", but it may
cause some compatibility problems.

Atsushi Onoe