Peter wrote:

>>> struct _packed_bits {
>>>  		 unsigned int bit0:1;
>>>  		 unsigned int bit1:1;
>>> } packed_bits;
>>
>> Now try to get the address of bit0, or to pass it to a function.
> 
> That is a pointer question ;-) You can pass only a pointer to modifiable
> data as an argument to a function. 

Bitfields /are/ modifiable data. It's just not possible to get the address
of a bitfield (whereas that works with other members of structs). In that
sense, bitfields are not fully integrated into the language.

> Therefore the limitation is that in C the *pointer* to the smallest
> entity is a pointer to an int (maybe to a char). No ? 

It's a pointer to char (and the size of a C char is an implementation thing
-- it's not defined in the language, even though in most implementations it
is a byte). But there's no inherent reason why there couldn't be a type
"bit" with a pointer to it. 

HiTech C (like many other "small processor C" implementations) has a type
"bit" -- it is a single bit, not surprisingly :) --, but no pointer to it.
I don't see a (language) reason why there couldn't be a pointer to a bit
type. They just would have to add some code to the compiler to properly
deal with this. 

In terms of efficiency, it doesn't matter whether you use a
struct/bitfield, bitwise-or or the bit type to set a single bit -- all
three cases the result is a single bsf instruction.

BTW, it /is/ possible to create a substitute for a bit pointer, using a
struct that contains a pointer to a byte and a bit address, together with
some functions that then set/clear/test the bit identified by such a
pointer. You just can't use the standard C pointer (de)referencing
operators & and * (that would require C++'s operator overloading...)

Gerhard
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist