According to Matthias Buelow:
>
>I agree that the bitfield notation is probably less error prone
>than the bit manipulation idioms but the fact that bitfields are
>"highly nonportable" [see below] make their use somehow inappropriate,
>especially in kernel code (were bit manipulation is often used on
>hardware register values).
>

Ummmm I would have thought this would be exactly the place where they
are best used.  Talking to hardware is so horribly intertwined with
the machine architecture that the portability of the code is pretty
much moot.  If you are porting to another architecture then you expect
these things to break.  In short, the kernel - at some level - is
machine dependent so if bit fields make things clearer, and I believe
the do, then they should be used.

>Yeah, I have the book open on my lap.  On page 183 it says,
>"Don't use C or C++ bitfields; they are highly nonportable and tend
>to generate voluminous and inefficient code". 

OK - I just tried this on i386 using a short bit of code and looking
at the assembly output.  If you just to sets and clears on bits (ie
thing.a = 1, thing.b = 0) then the code generated is very short, sharp
and sweet.  I don't think I could do better by hand.  If you do a
toggle of a bit using xor (thing.c ^= 1) then the compiler does
generate a lot of code but putting -O2 on seems to help markedly - the
code is not what I would have done by hand but it is not excessive.

>(S)he's got to weigh possible maintainance headache with bitfields,
>where (s)he basically doesn't see what the compiler does (except if
>(s)he disassembles it)

Heh - ``cc -S'' is your friend.

-- 
===============================================================================
Brett Lymn, Computer Systems Administrator, British Aerospace Australia
===============================================================================