In article <5v*************@mid.individual.net>,
Martin Ambuhl <ma*****@earthlink.netwrote:
>Bit-fields are portable. The manner in which they are stored becomes
important only when you write and read them, but that's true of _any_
variable written in one environment and read in another.
By "write and read them" I take it you mean "write and read them
to a stream (or file)". Whether that is what you meant is not
clear, but you might have perhaps not taken into account their
use in system interfaces. I don't -think- you mean the
vacuous statement that "if you just leave them sitting in memory
and do not use them in any way, then the manner in which they
are stored is not important."
The maximum bit-field size is not entirely specified. It
is a constraint violation if the number of bits specified exceeds
the number of bits in an "ordinary object" of the specified type,
int, signed int, unsigned int, or (C99) _Bool . However, the
underlying sizes of those objects is not fixed, so a bit-field
size of (say) 30 is valid on an implementation where int is 30 or more
bits, but not valid on an implementation where an int is only 16 bits.
For portability, one should thus restrict one's bitfields to 16 bits.
Unfortunately it is not uncommon for real interfaces to
be specified in terms of 32 bit words, and it is a nuisance to
portably synthesize a bit-field that crosses a 16 bit boundary.
The implementation is permitted to allocate any memory unit big
enough to hold the bitfield, so the implementation might choose
(for example) to pack a structure of bitfields inside a long
(say 32 bits) while not providing the tools to get the fields
where you want. For example, what does the following mean?
struct atest { unsigned int a:3; unsigned int b:16; unsigned int c:13 };
If the maximum memory unit size the implementation uses is 16 bits
(assuming the int is normally 16 bits), then this would be
(a, padding, b, c, padding) or (padding, a, b, padding, c) for
a total of 3 ints storage. But if the maximum memory unit size the
implementation uses is 32 bits (even through the int is normally 16),
or if int is 32 bits, then it would all get packed into 32 bits.
Stranger variations are possible for memory allocation unit
sizes from 20 to 32...
As you correctly point out (or imply), the padding differences are
A Problem for any kind of I/O stream interpreted by a different system,
but the variations in the maximum bit-field sizes make a code portability
difference, and the variations in the memory allocation unit together
with the variations in the maximum bit-field sizes can result in
having to piece together a structure literally bit-by-bit when
trying to do interoperability.
--
"History is a pile of debris" -- Laurie Anderson
