59 sensor[hunsoo]:/user4/hunsoo> cat a.c
#include <stdio.h>
typedef unsigned char uchar_t;

struct byte {
        uchar_t b_port:4,
                b_value:4;

        by.b_port = 5;
        by.b_value = 5;

        printf("0x%2x\n", *(uchar_t *) &by);
        return 0;

I am confused by the warning messages of gcc when I compiled
the above a.c because I think I did not make anything wrong.

Anyway what does the line 'a.c:5: warning: bit-field `b_port' type invalid
in ANSI C' mean?  Did I viloate some unknown
rule of the standard c?

------------
Hong Hunsoo
dep.of.physics of KAIST
Korea Advanced Institute of Science and Technology                        

--
(initiator of the campaign for grumpiness where grumpiness is due in c.l.c)

Attempting to write in a hybrid which can be compiled by either a C compiler
or a C++ compiler produces a compromise language which combines the drawbacks
of both with the advantages of neither.

??o????...

struct ip {
#if defined(vax) || defined(i386)
        u_char  ip_hl:4,                /* header length */
                ip_v:4;                 /* version */
#endif
#if defined(mc68000) || defined(sparc)
        u_char  ip_v:4,                 /* version */
                ip_hl:4;                /* header length */
#endif
        u_char  ip_tos;                 /* type of service */
        short   ip_len;                 /* total length */
        u_short ip_id;                  /* identification */

-----------------------
Hong Hunsoo
dep.of.physics of KAIST
Korea Advanced Institute of Science and Technology                

: 59 sensor[hunsoo]:/user4/hunsoo> cat a.c
: #include <stdio.h>
: typedef unsigned char uchar_t;

: struct byte {
:         uchar_t b_port:4,
:                 b_value:4;
: };

: int
: main(void)
: {
:         struct byte by;

:         by.b_port = 5;
:         by.b_value = 5;

:         printf("0x%2x\n", *(uchar_t *) &by);
:         return 0;
: }
: 60 sensor[hunsoo]:/user4/hunsoo>
: 62 sensor[hunsoo]:/user4/hunsoo> make a
: gcc -Wall -pedantic -ansi -g    a.c   -o a
: a.c:5: warning: bit-field `b_port' type invalid in ANSI C
: a.c:6: warning: bit-field `b_value' type invalid in ANSI C

This means the type's invalid in ANSI C - bitfields must be
some sort of int.  Note that bitfields implementation varies
between compilers, and they are fairly non-portable objects.

: a.c: In function `main':
: a.c:17: warning: implicit declaration of function `printf'

But I don't know about this one.  It sounds as if it isn't
finding printf() in stdio.h, but that seems unlikely.

Will

Before you complain to whoever supplied this header file: If you bought a
compiler, and the compiler came together with this file ip.h, and the
compiler documentation says that <ip.h> is a standard header file of this
compiler, then it is a part of the compiler and doesnt have to be legal C
at all - as long as the original compiler accepts #include <ip.h>.

Huh.. Why on earth did the ANSI-C makers dicide to consider the
'uchar a:4' as an invalid one.  It seams to me that they did
wrong things, made wrong ANSI-C, wrong, unnatural standard.  I
think if the 'bitfields of an int' are valid, then the 'bitfields
of char' should be valid ones.   Like if there exists an 'unsigned
int', the existence of 'an unsigned char' is natural one.  For me
the bitfields of char is very important because I have to control
each bit pattern of a register in a board.   For example, for
the following a register, I am in a situation of controlling
each bit at my will,

+------+------+------+------+------+------+------+------+
|  W2  |  W1  |  W0  | INTR | DMA  | PORT2|PORT1 |PORT0 |
|      |      |      |      |      |      |      |      |
+------+------+------+------+------+------+------+------+

And I imagined that if I create a structure like follwoing,

struct some_register {
        uchar_t r_wait:3,
                r_intr:1,
                r_dma:1,
                r_port:3;

Dont take my words seriously.  I just want to know why did the ANSI-C
dicide to take the 'bitfields of a char' as invalid....

---
Hong Hunsoo
dep.of.physics KAIST
Korea Advanced Institute of Science and Technology

...

--
-----------------------------------------


-----------------------------------------

--

If it ain't analogue, it ain't music.
#include <disclaimer.h>                          \\|// - ?
                                                 (o o)
          /==================================oOOo=(_)=oOOo========\

          |                                                       |
          |                                                       |
          |                          WWW: www.rkdltd.demon.co.uk  |
          |                                 .oooO                 |
          |                                  (  )  Oooo.          |
          \===================================\ (==(   )==========/
                                               \_)  ) /
                                                   (_/

As the actual storage size is given by the bit field the result is the
same.

On the other hand restricting bit fields so they can't use char seems
a fairly arbitrary restriction. And it could cause inconvenience (though
no loss of function) when using typedefs that you might have to type
the bit field separately.

Now bit fields of long might be useful, then one could reliably
have more than 16 bits in a bit field.

Another way of viewing the type of bit fields would be that the bit field
specification acts like short and long to modify the int type. So you
would only be able to have a bit field of [unsigned | signed] int. Anything
else would be like writing short char or long short int. However that would
rule out using any typedefs for the type of a bit field. I do not think
this is they way the standard currently views it.

--

Philips Semiconductors Ltd                  
Southampton SO15 0DJ                        +44 (01703) 316431
United Kingdom                              My views are my own.
Do you use ISO8859-1? Yes if you see ? as copyright, as division and ? as 1/2.

        struct some_register {
          unsigned r_wait:3,
                   r_intr:1,
                   r_dma:1,
                   r_port:3;
        };

Can't you manipulate now your register as easily ?

Further I think there is still a general misunderstanding. You
probably may think that, because you defined your bit field struct
members of type unsigned int, sizeof(struct some_register) will be
necessarily be equal to sizeof(unsigned int). This is not the case.
The compiler may choose any appropriate addressable storage unit to
"host" an  adjacent bit-field sequence - even a byte/char.

So, in fact, your bit-fields are "mental" objects and the mapping of a
bit-field sequence to a "physical" bit string is not pecified by the
standard. Even the order in which adjacent bit-fields are stored in
their host storage unit is to be defined by the implementation.

Regards
Horst

   *** Las orillas del Nahuel Huapi ***

I am using an implementation that allows bitfields of
type (unsigned) char.  The difference between a char bitfield and a
int bitfield is the size of the resulting struct.  The char bitfields
result in the allocation unit being 8 bits, while the int bitfields
result in the allocation unit being 16 bits (int size).  This DOES
make a difference when it is embedded in another structure or array.

The ANSI C89 version of the standard says that "An implementation may
allocate any addressable storage unit large enough to hold a
bit-field."  The implementation thus has license to only allocate a
byte if the declared bitfields fit, but I have not seen such an
implementation.  I think there would be definite benefit for this.

 > struct some_register {
 >         unsigned int r_wait:3,
 >                      r_intr:1,
 >                      r_dma:1,
 >                      r_port:3;
 > };

 > This does exactly the same thing as your declaration would do if it were
 > legal. It says that there's a field named r_wait with 3 bits, followed
 > by some unspecified padding, followed by a field named r_intr with 1
 > bit, followed by some unspecified padding, followed by a field named
 > r_dma with 1 bit, followed by some unspecified padding, followed by a
 > field named r_port with 3 bits.

The standard does not allow for arbitrary padding between bitfields.
They must be ajacent, except that when crossing a boundary the
implementation is allowed to pad out the remaining allocation unit. In
particular, no implementation is permitted to place padding between
r_wait and r_intr, although if the storage unit is 3 bits wide, it may
jump to the beginning of the next storage unit.

Such padding is not required and I know of one implementation in which
fields cross allocation unit boundaries with no padding.  

 > You could do exactly the same with:
 >  struct some_register {
 >          unsigned int r_wait:3,
 >                  r_intr:1,
 >                  r_dma:1,
 >                  r_port:3;
 >  };

 > As the actual storage size is given by the bit field the result is the
 > same.

The difference, for an implementation I am familar with, is that the
size of the struct is sizeof(int) in one case and 1 in the other.

Thad

However, consider the ramifications of allowing 'char' and 'short'
bitfield types as well.  What happens when you do this (on an 8-bit
system)?:

    struct Bittle
    {
        unsigned char   a: 3;
        unsigned char   b: 9;   /* Oops */
        unsigned short  c: 20;  /* Oops */
    };

It would appear that allowing 'long' and 'long long' bitfield types
would be useful.  But while section 6.5.2.1 of the standard (both
C89 and draft C9X) states that 'int', 'signed int', or
'unsigned int' are the only explicitly allowed types, it does not
state that the width of bitfields is limited to the width of 'int';
rather, it states that "a bitfield is interpreted as an integral type
consisting of the specified number of bits".  This implies that the
bitfield width could be the number of bits in *any* integral type,
including 'long' and 'long long'.

So it looks like C already has long bitfields.  Presumably, then,
the following is portable and conforming:

    struct Widdle
    {
        unsigned int    a: 24;  /* More than the minimum 16 bits */
        unsigned int    b: 8;
    };

    struct Widdle       w;
    long int            i;      /* Will be at least 32 bits wide */

    w.a = 0x00FFFFFF;           /* Set all bits of w.a to 1 */
    w.b = 0x00;                 /* Set all bits of w.b to 0 */

    i = w.a;                    /* Should be no loss of bits */
    assert(i == w.a);           /* Should be true, portably */
    assert(i == 0x00FFFFFF);    /* Should be true, portably */

What is the use of a bit-field that is an unsigned char? All that means is
that it can't be wider than CHAR_BIT.

        unsigned char x : 8;

versus

        unsigned x : 8;

Both of them have the same range of values, and there is no guarantee
that the non-portable variant will use less storage. If the C committee
changed the language to allow unsigned char to be a base type for a bit-field,
I doubt that they would impose additional requirements that  bitfields
of a smaller type should occupy less space than bitfields of a larger type.

You can see this usefulness of 'bitfields of

I could make the same argument about any GCC extension that is used
in Linux header files: see how useful it is to mark a non-returning
function with a suitable __attribute__ ((noreturn)) ? It should
be in the language!

All I see is a header file that fails to conform to the C language,
and which makes it potentially difficult to use some source code tools which
operate pre-processed output, and expect to be able to parse the output using
the ANSI C grammar and ANSI C constraint checks.

ANSI C makes it a constraint violation if the bit field width exceeds
the size of the bit-field's type, even if that type is other than int.

I've used bitfields of unsigned int type quite frequently, for example to save
space in representing various object flags:

        struct connection {
                unsigned allocated : 1;
                unsigned connected : 1;
                unsigned direction : 2;
        };

Such declarations are written in the hope that the bitfields will be packed
into a single unit of storage to save space, at the possible cost of access
time.  The size of the unit of storage is implementation-defined, and as such
is of little interest in portable coding situations.

In GCC, the _only_ advantage you gain by using an unsigned char bitfield
is that the compiler will use a smaller unit size for allocating the
bitfields, so that accessing a bitfield causes a single byte memory
transfer, rather than a word memory transfer (on machines that support
byte transfers, of course).

There are some additional things you might want to know about bitfields.

You can have unnamed bitfields:

        unsigned : 2;

These serve the purpose of padding. You can also have unnamed bitfields
of size zero:

        unsigned : 0;

The purpose of these is to force the _next_ bitfield to lie in a new
storage unit rather than be packed into the previous storage unit.

Also, it is implementation-defined whether a bitfield can straddle two
adjacent storage units. For example, if the storage unit is 16 bits
wide, it is implementation defined whether

        unsigned a : 15;
        unsigned b : 3;

will place the b into the next storage unit, or whether it will put one bit
of it into the first storage unit, and two bits into the next. However,
if you write

        unsigned a : 15;
        unsigned : 0;
        unsigned b : 3;

you can be sure that the b will go into the new storage unit.

Of course, if you are worried about things like that, you are no longer
writing in portable C.

The only thing you can portably do with bitfields is to use them as small
integral types in an attempt to save space.