Mail Archives: djgpp/2001/10/04/21:19:19
CBFalconer wrote:
>
> Graham Warren wrote:
> >
> > I have a question about bit-fields.
> >
> > In a program I have defined a bit-field using the code shown below.
> >
> > /* define bit-field */
> >
> > struct {
> > unsigned int b0 : 1;
> > unsigned int b1 : 1;
> > unsigned int b2 : 1;
> > unsigned int b3 : 1;
> > unsigned int b4 : 1;
> > unsigned int b5 : 1;
> > unsigned int b6 : 1;
> > unsigned int b7 : 1;
> > } bit_field;
> >
> > /* */
> >
> > My questions are: would bit_field.b0 be the furthest left or furthest right
> > bit if the byte is written out 00000000?
> > Would this change if more bits were defined in the bit field to make it
> > spill over into a larger than 1 byte area?
> >
> > Also which bit in 00000000 is referred to as the most-significant and which
> > is the least-significant?
>
> Who knows. It is implementation dependant, and should not be used
> in portable code.
I disagree. It is indeed implementation dependent, but it is
not significntly less portable.
The alternative is to use masks and shifts, or custom
routines, either of which are clumsier and harder to
port, in my opinion. This opinion was formed after
doing both.
If you use bit fields, you simply have to account for bit position
in struct/typedef declarations in included .h files, and the remainder
of the code remains untouched.
It's a shame there was no standard specified for ordering of bit
fields in 'C', because that would have been a nice way to handle
memory and I/O mapped hardware interfaces very portably.
>
> --
> Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT XXXXworldnet DOT att DOT net)
> (Remove "XXXX" from reply address. yahoo works unmodified)
> mailto:uce AT ftc DOT gov (for spambots to harvest)
--
http://home.att.net/~lcargill
- Raw text -