bitfields

[sinbad]

when should one decide to use c bitfileds.
i have a requirement where i should communicate
some data to a process. i decided to use bitfields
as follows.

struct bitfield_struct {
unsigned a_bit:1;
unsigned b_bit:1;
unsigned c_bit:1;
unsigned rbits:5;
unsigned data:24;
};

what things one should consider while using bitfields ?
and No the object defined with above struct will not be
accessed from multiple threads, it purely used to send
some data to other process by using some ipc mechanism.
surprisingly c-faq doen't have anything related bitfields.
time to add one ?

 

[Eric Sosman]

when should one decide to use c bitfileds.
i have a requirement where i should communicate
some data to a process. i decided to use bitfields
as follows.

struct bitfield_struct {
unsigned a_bit:1;
unsigned b_bit:1;
unsigned c_bit:1;
unsigned rbits:5;
unsigned data:24;
};

what things one should consider while using bitfields ?
and No the object defined with above struct will not be
accessed from multiple threads, it purely used to send
some data to other process by using some ipc mechanism.
surprisingly c-faq doen't have anything related bitfields.
time to add one ?

One concern about bit-fields is that you can't form pointers
to them. You can form a pointer to the containing struct, but
not to any of the individual bit-fields within it. Similarly,
you cannot use `sizeof' or `offsetof' or `_Alignof' on a bit-field.

The allowable width is another concern. The "nominal" type
of a bit-field is some form of `int' or `_Bool', and the number
of bits specified cannot exceed the number of bits in that nominal
type. Since an `int' might be as narrow as 16 bits, some compilers
may reject the 24-bit `data' element in your example.

A third concern is that compilers have considerable freedom
in how they arrange bit-fields, and different compilers may do it
differently. If the source machine sets `a_bit' to 1 and all the
other fields to zero and sends the resulting bytes to a program
built with a different compiler, the receiver may find that the
lone 1-bit is in the `data' element instead of in `a_bit'. (This
is a concern even when bit-fields are not involved since machines
may disagree on "endianness" and so on, but it's an even greater
concern when bit-fields are involved.)

IMHO, bit-fields are less useful than they may at first appear.
If you plan to handle very many instances of a struct, bit-fields
can economize memory use, I/O size, and so on. But if you've got
only a few hundred instances the savings from using bit-fields is
usually too small to warrant the headaches.

 

[Ike Naar]

surprisingly c-faq doen't have anything related bitfields.
time to add one ?

You missed this: http://c-faq.com/struct/bitfield0.html ?

 

[Joe Pfeiffer]

One concern about bit-fields is that you can't form pointers
to them. You can form a pointer to the containing struct, but
not to any of the individual bit-fields within it. Similarly,
you cannot use `sizeof' or `offsetof' or `_Alignof' on a bit-field.

The allowable width is another concern. The "nominal" type
of a bit-field is some form of `int' or `_Bool', and the number
of bits specified cannot exceed the number of bits in that nominal
type. Since an `int' might be as narrow as 16 bits, some compilers
may reject the 24-bit `data' element in your example.

A third concern is that compilers have considerable freedom
in how they arrange bit-fields, and different compilers may do it
differently. If the source machine sets `a_bit' to 1 and all the
other fields to zero and sends the resulting bytes to a program
built with a different compiler, the receiver may find that the
lone 1-bit is in the `data' element instead of in `a_bit'. (This
is a concern even when bit-fields are not involved since machines
may disagree on "endianness" and so on, but it's an even greater
concern when bit-fields are involved.)

IMHO, bit-fields are less useful than they may at first appear.
If you plan to handle very many instances of a struct, bit-fields
can economize memory use, I/O size, and so on. But if you've got
only a few hundred instances the savings from using bit-fields is
usually too small to warrant the headaches.

The best rule I've come up with regarding bit fields is "don't". Just
don't use them. I'm responding to Eric instead of the OP because Eric
is doing a good job describing specific concerns with them; my
experience was with writing programs that made extensive use of them,
which I had to port from a little-endian machine to a big-endian, and
the pain was really not worth it. Writing macroes that do the masks and
shifts "by hand" in a fixed-width variable and then using those macroes
will cost you a little bit up front, but will save immensely in
maintenance over time.

 

[Nobody]

when should one decide to use c bitfileds.

1. When you really, really need to minimise the size of the structure,
you don't need to be able to have pointers to individual fields.

2. When you need to manipulate a pre-existing data format which uses
bitfields heavily and you're targeting a specific compiler. Compilers for
embedded platforms frequently do this for hardware registers. The Linux
kernel headers (which specifically target gcc) do it for networking
packets, data structures hard-wired into the CPU, etc.

 

[itc.vijay]

1. When you really, really need to minimise the size of the structure,
you don't need to be able to have pointers to individual fields.

2. When you need to manipulate a pre-existing data format which uses
bitfields heavily and you're targeting a specific compiler. Compilers for
embedded platforms frequently do this for hardware registers. The Linux
kernel headers (which specifically target gcc) do it for networking
packets, data structures hard-wired into the CPU,

bitfield?

 

[Guest]

when should one decide to use c bitfileds [?]
never

i have a requirement where i should communicate
some data to a process. i decided to use bitfields
as follows.

and what happens when you change compilers?

struct bitfield_struct {
unsigned a_bit:1;
unsigned b_bit:1;
unsigned c_bit:1;
unsigned rbits:5;
unsigned data:24;
};

what things one should consider while using bitfields ?

their extreme non-portability

and No the object defined with above struct will not be
accessed from multiple threads, it purely used to send
some data to other process by using some ipc mechanism.
surprisingly c-faq doen't have anything related bitfields.
time to add one ?

if i did it it would be very short

 

[Guest]

bitfield?

are you trying to ask a question?

 

[Ian Collins]

when should one decide to use c bitfileds [?]

never

Harsh, I've used them frequently in driver and protocol code.

and what happens when you change compilers?

You make sure it uses the same ordering. I've never come across
different compilers on the same target using different bit field ordering.

their extreme non-portability

There aren't any guarantees, but they are generally pretty portable.

 

[Ben Bacarisse]

when should one decide to use c bitfileds [?]

never

("Bull, have you met my friend Red Rag?")

They can sometimes be useful for saving space. For example, with an
implementation that has sizeof(long) == sizeof(int) == sizeof(short)
using bitfields for integer quantities that don't need to be as wide as
int might save a lot of space. In effect the bit field is a way to say
to the compiler "I am sufficiently concerned about space here that I am
prepared to pay the price of shifting and masking and I'd like you to do
it for me".

<snip>

 

[Malcolm McLean]

בת×ריך ×™×•× ×©×œ×™×©×™, 26 ביוני 2012 11:48:37 UTC+1, מ×ת Ben Bacarisse:

(e-mail address removed) writes:

They can sometimes be useful for saving space. For example, with an
implementation that has sizeof(long) == sizeof(int) == sizeof(short)
using bitfields for integer quantities that don't need to be as wide as
int might save a lot of space. In effect the bit field is a way to say
to the compiler "I am sufficiently concerned about space here that I am
prepared to pay the price of shifting and masking and I'd like you to do
it for me".

if you need a character and associated integer, usually 24 bits will be enough for the integer.

 

[Guest]

On Thursday, June 14, 2012 1:05:51 PM UTC+1, sinbad wrote:

when should one decide to use c bitfileds [?]

never

Harsh, I've used them frequently in driver and protocol code.

i have a requirement where i should communicate
some data to a process. i decided to use bitfields
as follows.

and what happens when you change compilers?

You make sure it uses the same ordering. I've never come across
different compilers on the same target using different bit field ordering.

I read somewhere that MS managed to change the ordering of bit fields
between two successive versions of their C compiler. But hopefully such
events are very rare.

There aren't any guarantees, but they are generally pretty portable.

I'm surprised. It was some time ago I ran into trouble with two compilers. And once bitten...

There are two main uses of bitfields. One is for packing data
efficiently, which can be very useful for large data structures. The
other is to map to existing structures - typically hardware registers.

the third is for building PDUs (messages) to transfer data between processors. This I found to be problematic.

In the first case, the ordering doesn't matter, so portability is a
non-issue. It just has to be consistent across the program that uses
the data.

In the second case, ordering must match the external structure or
hardware. But again, portability is a minor concern - quite simply
because you don't change compilers when you are working on such
low-level code, and the code is inherently non-portable.

but with the PDU example the two processors may be radically different and employ horridly different compilers. I now write bit portable extracting code. Once you have such a libary its not much harder to use than bitfields and probably about as effcient.

So for most purposes, bitfields as as portable as they need to be.

up to a point...

There are a few situations when you need to be extra careful. An
example would be bitfields used for structures in a file system - you
need it to be consistent across a wide variety of architectures. But
then the bitfields are not the only thing you have to worry about -
endianness, alignment, padding, etc., are just as important. And when
you do the work needed to ensure that these are correct, it's a simple
matter to make the bitfields work too.

simple?!

 

[Guest]

when should one decide to use c bitfileds [?]

never

("Bull, have you met my friend Red Rag?")

he's a relative beginner I like to keep things simple! I suppose I mean "hardly ever". but to be honest I haven't seen fit to do so in decades. I've used more gotos than bitfields. About as useful as continue or union.

 

[Jorgen Grahn]

On Thursday, June 14, 2012 1:05:51 PM UTC+1, sinbad wrote:

when should one decide to use c bitfileds [?]

never

Harsh, I've used them frequently in driver and protocol code.

i have a requirement where i should communicate
some data to a process. i decided to use bitfields
as follows.

and what happens when you change compilers?

You make sure it uses the same ordering. I've never come across
different compilers on the same target using different bit field ordering.

I read somewhere that MS managed to change the ordering of bit fields
between two successive versions of their C compiler. But hopefully such
events are very rare.

So did Lattice C on the Amiga some time in the 1990s. That's when I
learned not to trust such things.

IMO, if you want to hardcode towards one specific bitfield layout, you
need written proof (documentation) of the compiler's layout, and your
build system needs to contain tests which fail if some other layout is
in effect.

/Jorgen