.TH "bit-fields" "" "" Definition
.II word
.PC
.PP
A
.I bit-field
is a member of a structure or
.B union
that is defined to be a cluster of bits.
It provides a way to represent data compactly.
For example, in the following structure
.DM
	struct example {
		int member1;
		long member2;
		unsigned int member3 :5;
	}
.DE
.PP
.B member3
is declared to be a bit-field that consists of five bits.
A colon \*(Ql:\*(Qr precedes
the integral constant that indicates the \fIwidth\fR, or the
number of bits in the bit-field.
Also, the bit-field declarator
must include a type, which must be one of
.BR int ,
.BR "signed int" ,
or
.BR "unsigned int" .
.if \nX=4 \{\
If a bit-field is declared to be in type
.BR int ,
the implementation defines whether the highest bit is used to hold
the bit-field's sign. \}
.if \nX=4 \{\
.PP
The Standard states, \*(QLAn implementation may allocate any addressable
storage unit large enough to hold a bit-field.\*(QR
This suggests that if a bit-field is defined as holding more bits
than are normally held by an
.BR int ,
then the implementation may place the bit-field into a larger
data object, such as a
.BR long . \}
.if \nX=4 \{\
.PP
If two bit-fields are declared side-by-side and together are small
enough to fit into an
.BR int ,
then they must be packed together.
However, if together they are too large to fit into an
.BR int ,
then the implementation determines whether they are in separate objects
or if the second bit-field is partly within the object that holds the first
and partly within a second object.
.PP \}
.if \nX=4 \{\
The implementation also defines where the bit-field resides within its
object \(em whether it is built from the low-order bit up, or from
the high-order bit down.
For example, consider an implementation in which an
.B int
has 16 bits.
If a five-bit bit-field is declared to be part of an
.BR int ,
and that bit-field is initialized to all ones, then the
.B int
may appear like this under one implementation:
.DM
	0000 0000 0001 1111	/* low-order bits set */
.DE
.PP
and like this under another:
.DM
	1111 1000 0000 0000	/* high-order bits set */
.DE \}
.PP
A bit-field that is not given a name may not be accessed.
Such an
object is useful as \*(QLpadding\*(QR within an object so that it
conforms to a template designed elsewhere.
.PP
A bit-field that is unnamed and has a length of zero can be used to
force adjacent bit-fields into separate objects.
For example, in the following structure
.DM
	struct example {
		int member1;
		int member2 :5;
		int :0;
		int member3 :5;
	};
.DE
.PP
the zero-length bit-field forces
.B member2
and
.B member3
to be written into separate objects.
.PP
Finally, it is illegal to take the address of a bit-field.
.SH "See Also"
.Xr bit, bit
.Xr "bit map," bit_map
.Xr byte, byte
.Xr "Programming COHERENT," programmi
.br
\*(AS, \(sc3.5.2.1
.SH Notes
Because bit-fields have many implementation-specific properties,
they are not considered to be highly portable.
Bit-fields use minimal amounts of storage, but the amount of computation needed
to manipulate and access them may negate this benefit.
Bit-fields must be kept in integral-sized objects
because many machines cannot directly
access a quantity of storage smaller than
a \*(QLword\*(QR (a word is generally used to store an
.BR int ).
