In message <199511260727.CAA03122@south.mit.edu> you said:
> ...
> Also, you can put in many blanks for future expansion by doing this:
> ...
> aff_hide : 1
> extras : 100
> }
> then to add a new one, simply:
> ...
> aff_hide : 1
> aff_new : 1
> extras : 99 /* pfile is not corrupted */
> }
> The size of the bitfield in bytes will be the number of bits allocated,
> divided by 8, rounded up.
This is a false assumption. From Kernighan & Ritchie, "All aspects of
the implementation of bitfields are undefined." That may not be an exact
quote as I don't have my copy in front of me, but you get the idea. PFor
all you know, the compiler may be allocating an entire byte for each
bitfield variable! Granted, I am proposing an extreme case, but you never
know. For that same reason, you can not assume that the two structures
listed above will be structured identically in memory.
I was under the impression that you can do the following with a bitfield:
Say you want to read in a status byte from a piece of hardware, but are only
interested in, say, the 5th and 6th bytes. You can:
...
struct status_byte {
unsigned buf : 4; /* this will hold the first 4 bytes */
unsigned status_5 : 1;
unsigned status_6 : 1;
unsigned buf2 : 2;
...
This will accurately allow you to get just the 5th and 6th bytes, or at least
it should, otherwise bitfields wouldn't be nearly as useful! So I guess I'm
not sure, will it?
This archive was generated by hypermail 2b30 : 12/07/00 PST