Since you can't access its value at all (stupid tricks with unsigned
char pointers aside), and that value is therefore irrelevant, yes.
C trivia question: Is it possible to access the value of an unnamed
bit-field in a way that's portable and not implementation dependent?
Answer: of course there are implementation dependent ways (besides
using unsigned chars, there are other kinds of type punning, or
reading/writing a binary file), but it may surprise some people to
know that there is also a portable way to do so:
struct s {
unsigned foo : 4;
unsigned : 12;
unsigned bas : 16;
};
struct t {
unsigned foo : 4;
unsigned hidden : 12;
unsigned bas : 16;
};
union s_and_t {
struct s s;
struct t t;
} s_and_t;
/* now using s_and_t.t.hidden will access */
/* the unnamed bit-field in s_and_t.s */
Furthermore this technique could be useful in implementing a
semi-opaque type, using one type as the public type, and another
type to access the "hidden" members.
In y, yes, but they're irrelevant; in x, they're not even guaranteed to
be zero.
In fact I think they are. I can't find any provision in the
Standard that suggests they needn't be copied along with every
other member. There is one case where unnamed bit-fields are
handled differently, and that is initialization. 6.7.8 p 9 says:
Except where explicitly stated otherwise, for the purposes of
this subclause unnamed members of objects of structure and union
type do not participate in initialization. Unnamed members of
structure objects have indeterminate value even after
initialization.
But note 6.7.8 p 13:
The initializer for a structure or union object that has
automatic storage duration shall be either an initializer list
as described below, or a single expression that has compatible
structure or union type. In the latter case, the initial value
of the object, including unnamed members, is that of the
expression.
Considering this, and considering the absence of any statement
that says unnamed bit-fields are treated differently during
assignment, I propose the most reasonable conclusion is that the
Standard expects them to be copied just as other members are.
(because structures are not allowed to have padding at the beginning)?
Structures are not allowed to have _implementation-inserted_ padding
_bytes_ at the beginning. You, as the user-programmer, are allowed to
add as much padding of your own as pleases you. There is nothing in the
Standard to stop you from declaring
struct t {
unsigned char padding[37];
long int single_data_member;
unsigned char more_padding[51];
}
Do not be surprised to find extra padding added after _your_ member
called padding, and before or after more_padding.
I admit, my question here is to a degree deliberately obtuse.
However, there's an important difference between the question
that I asked and the example "padding" members in the example
above, in that there is nothing in the Standard that suggests
that it would put the latter under the label of 'padding', whereas
as there is a _hint_ of such suggestion for unnamed bit-fields.
(A footnote in 6.7.2.1 p 11.) I don't really think this
means that unnamed bit-fields are padding the sense that
normative passages in the Standard use the term, but
certainly we should expect the Standard to be consistent
as to its viewpoint on this question. Shouldn't we?
Tell me, did you _really_ not know all this, or are you being an awkward
arsehole just to make the point that you _can_ be an awkward arsehole?
I usually don't think of myself as an ass**** (either awkward or
otherwise), but if/when I do there doesn't seem to be any point to
making a statement solely for the purpose of pointing that out.
In this particular case, there are several points that I think
are of general interest to newsgroup readers. One: is structure
assignment required to copy unnamed bit-fields? (I believe it
is, other people may have different opinions.) Two: there is a
portable way to access values of bit-field members. Three: the
word 'padding' is used in several different senses in the
Standard, mostly without any definition, and in fact it's not
clear how many different senses there are, or which ones are
which in all cases. So, when making a statement about padding in
comp.lang.c, it's a good idea to be clear about which sense of
the word one is referencing, especially if it's different from,
or might be different from, the several ways that the Standard
uses the term.