«

Keith Thompson <kst-> writes:

> Tim Rentsch <> writes:
> > Keith Thompson <kst-> writes:
> >> Tim Rentsch <> writes:
> [...]
> >> > There is also the footnote in 6.2.6.1 p 6, which mentions "padding
> >> > bits", presumably meaning to cover "padding bytes" for structs/unions,
> >> > and also the unused bits between (or after) members when one of
> >> > them is a bit-field. (Of course, "padding bytes" also covers
> >> > extra bytes at the end of a union.)
> >>
> >> Hmm. I suspect that was a typo for "padding bytes".
> [...]
> > It seems more likely that "padding bits" is what was
> > actually meant, meaning to cover both the cases of
> > whole bytes in between members, and also partial
> > bytes (bits) in between members.
>
> But the phrase "padding bits" is specifically used to refer certain
> bits in integer representations. Even if "padding bits" is what was
> meant here, there needs to be some more wording clarifying just what
> that means.

I agree, absolutely.


> > But it raises an interesting question. If there is
> > a partial byte of unused memory (following a bit-field
> > member, and before the subsequent member), are those
> > bits guaranteed to be left unchanged by assignment
> > to the bit-field member (or other members, but that's
> > the obvious one)? Those bits don't correspond to
> > any padding bytes, and so aren't covered by 6.2.6.1p6.
>
> I don't think there'd be any benefit in guaranteeing that such bits
> are unchanged. On the other hand, an implementation would have to go
> out of its way to leave such bits undefined. On the other other hand,
> it might make sense to do so; for example, an implementation might try
> to guarantee that all padding is set to zero (unless you use something
> like memset to set it to something else).

If I had to bet (at even money, presumably) on how
the committee would vote on this question, I would
bet the vote would go in favor of having the values
of unused bits (with less than a byte's worth)
having unspecified values. (Can a single bit
even hold a trap representation?)

However, I meant only to ask the question of what
the Standard currently does say on the question, not
what it should say.

Keith Thompson <kst-> wrote:

> (Richard Bos) writes:
> > Eric Sosman <> wrote:
> >> Richard Bos wrote:
> >> > What's more, padding is never a data member at all. The defining
> >> > characteristic of padding is that it exists because of the space it
> >> > takes, not because of the value it may or may even never have. Any data
> >> > member, even a data member only few people find useful, should at some
> >> > point in its life have a value that those people want to refer to.
> >> > Padding may change randomly or never at all, and you can blot over it
> >> > without affecting anyone.
> >>
> >> So I guess you'd say "unused; must be zero" bits are
> >> not padding?
> >
> > That depends on whether that is a political or a technical "must". If
> > there is reasonable expectation that it may in the future be used, and
> > can then get other values, it's not. If it's only required to be zero
> > out of a show of future planning, it's padding. I admit that this may,
> > for an outsider, be difficult to judge.
>
> There are at least three distinct meanings of "padding".
>
> The C standard defines "padding bits" for integer types, and "padding
> bytes" for structs.

As far as I can tell, both of those fall under my definition of padding
above. In neither case is the contents of those bits relevant to the
programmer.

> What we're talking about here is what "padding" means in a non-C
> context. I know of no rigorous definition (say, one that excludes
> foam rubber), and no way to resolve any disagreements about whether an
> unused byte in an IP packet qualifies as "padding".

If it's actually unused, again, I think that falls under the above
definition of "a member whose only important feature is its size, and
whose contents is irrelevant".

Richard

Tim Rentsch <> wrote:

> (Richard Bos) writes:
>
> > 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.

> > 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.

Well, I'm sorry, but I find post-modernism only extremely irritating in
a lit crit context, but downright anathema in a computing discussion. So
don't expect me to take it seriously.

Richard

(Richard Bos) writes:

> Tim Rentsch <> wrote:
>
> > (Richard Bos) writes:
> >
> > > 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.
>
> > > 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.
>
> Well, I'm sorry, but I find post-modernism only extremely irritating in
> a lit crit context, but downright anathema in a computing discussion. So
> don't expect me to take it seriously.

I see you ignored all the technical content of my message
(82 lines) and chose to focus instead on just the four
lines quoted above (three of which are there only because
of your previous somewhat rudely phrased question). In
the earlier case it seemed right to give you the benefit
of the doubt. The doubt is now removed; clearly what I
should expect in the future is that you might ignore any
statement at any time whenever it suits your purposes.

On 25 June, 18:20, Tim Rentsch <t...@alumnus.caltech.edu> wrote:
> ralt...@xs4all.nl (Richard Bos) writes:
> > Tim Rentsch <t...@alumnus.caltech.edu> wrote:
> > > ralt...@xs4all.nl (Richard Bos) writes:


> > > > What's more, padding is never a data member at all. The defining
> > > > characteristic of padding is that it exists because of the space it
> > > > takes, not because of the value it may or may even never have. Any data
> > > > member, even a data member only few people find useful, should at some
> > > > point in its life have a value that those people want to refer to.
> > > > Padding may change randomly or never at all, and you can blot over it
> > > > without affecting anyone.
>
> > > In
>
> > > * * struct s {
> > > * * * unsigned foo : 4;
> > > * * * unsigned * * : 12;
> > > * * * unsigned bas : 16;
> > > * * };
>
> > > would you say the data member between foo and bas is there as
> > > padding?

I might, if say I was describing the format of a data packet.
I don't consider it "padding" in the C sense of the word.

> > Since you can't access its value at all (stupid tricks with unsigned
> > char pointers aside), and that value is therefore irrelevant, yes.

I think the "stupid trick" with unsigned char can't be ignored.

> 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?

no. Its very position is implementation defined

> 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:

surprise me

> * * 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 * * * **/

....and invoke Undefined Behaviour. You've replaced IB with UB.


<snip>

Nick Keighley <> writes:

> On 25 June, 18:20, Tim Rentsch <t...@alumnus.caltech.edu> wrote:
> > ralt...@xs4all.nl (Richard Bos) writes:
> > > Tim Rentsch <t...@alumnus.caltech.edu> wrote:
> > > > ralt...@xs4all.nl (Richard Bos) writes:
>
>
> > > > > What's more, padding is never a data member at all. The defining
> > > > > characteristic of padding is that it exists because of the space it
> > > > > takes, not because of the value it may or may even never have. Any data
> > > > > member, even a data member only few people find useful, should at some
> > > > > point in its life have a value that those people want to refer to.
> > > > > Padding may change randomly or never at all, and you can blot over it
> > > > > without affecting anyone.
> >
> > > > In
> >
> > > > struct s {
> > > > unsigned foo : 4;
> > > > unsigned : 12;
> > > > unsigned bas : 16;
> > > > };
> >
> > > > would you say the data member between foo and bas is there as
> > > > padding?
>
> I might, if say I was describing the format of a data packet.
> I don't consider it "padding" in the C sense of the word.
>
> > > Since you can't access its value at all (stupid tricks with unsigned
> > > char pointers aside), and that value is therefore irrelevant, yes.
>
> I think the "stupid trick" with unsigned char can't be ignored.
>
> > 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?
>
> no. Its very position is implementation defined
>
> > 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:
>
> surprise me
>
> > 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 */
>
> ...and invoke Undefined Behaviour. You've replaced IB with UB.

No, this is defined behavior, not undefined behavior.
Please see 6.5.2.3 p 5.

On 9 July, 11:30, Tim Rentsch <t...@alumnus.caltech.edu> wrote:
> Nick Keighley <nick_keighley_nos...@hotmail.com> writes:
> > On 25 June, 18:20, Tim Rentsch <t...@alumnus.caltech.edu> wrote:
> > > ralt...@xs4all.nl (Richard Bos) writes:
> > > > Tim Rentsch <t...@alumnus.caltech.edu> wrote:
> > > > > ralt...@xs4all.nl (Richard Bos) writes:
>
> > > > > > What's more, padding is never a data member at all. The defining
> > > > > > characteristic of padding is that it exists because of the space it
> > > > > > takes, not because of the value it may or may even never have. Any data
> > > > > > member, even a data member only few people find useful, should at some
> > > > > > point in its life have a value that those people want to refer to.
> > > > > > Padding may change randomly or never at all, and you can blot over it
> > > > > > without affecting anyone.
>
> > > > > In
>
> > > > > * * struct s {
> > > > > * * * unsigned foo : 4;
> > > > > * * * unsigned * * : 12;
> > > > > * * * unsigned bas : 16;
> > > > > * * };
>
> > > > > would you say the data member between foo and bas is there as
> > > > > padding?
>
> > I might, if say I was describing the format of a data packet.
> > I don't consider it "padding" in the C sense of the word.
>
> > > > Since you can't access its value at all (stupid tricks with unsigned
> > > > char pointers aside), and that value is therefore irrelevant, yes.
>
> > I think the "stupid trick" with unsigned char can't be ignored.
>
> > > 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?
>
> > no. Its very position is implementation defined
>
> > > 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:
>
> > surprise me
>
> > > * * 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 * * * **/
>
> > ...and invoke Undefined Behaviour. You've replaced IB with UB.
>
> No, this is defined behavior, not undefined behavior.
> Please see 6.5.2.3 p 5

what's the section titled, "Structure and Union Members"?
Or could you quote it? I don't have an ISO standard handy.

This is the "common initial sequence" bit? Interesting.

Tim Rentsch <> wrote:

> (Richard Bos) writes:
>
> > Tim Rentsch <> wrote:
> >
> > > (Richard Bos) writes:
> > >
> > > > 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.
> >
> > > > 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.
> >
> > Well, I'm sorry, but I find post-modernism only extremely irritating in
> > a lit crit context, but downright anathema in a computing discussion. So
> > don't expect me to take it seriously.
>
> I see you ignored all the technical content of my message
> (82 lines) and chose to focus instead on just the four
> lines quoted above

Yes, for exactly the reasons outlined above. I have better things to do
with my time than dragging someone's honest intentions out of them like
so many horse's teeth. You do not make a good Socrates, and while you
would probably make a good Derrida, I do not see this as a goal to be
encouraged. I'll pay attention to you again when you have not only
technical content, but also a discernable point.

Richard

Nick Keighley <> writes:

> On 9 July, 11:30, Tim Rentsch <t...@alumnus.caltech.edu> wrote:
> > Nick Keighley <nick_keighley_nos...@hotmail.com> writes:
> > > On 25 June, 18:20, Tim Rentsch <t...@alumnus.caltech.edu> wrote:
> > > > ralt...@xs4all.nl (Richard Bos) writes:
> > > > > Tim Rentsch <t...@alumnus.caltech.edu> wrote:
> > > > > > ralt...@xs4all.nl (Richard Bos) writes:
> >
> > > > > > > What's more, padding is never a data member at all. The definin=
> g
> > > > > > > characteristic of padding is that it exists because of the spac=
> e it
> > > > > > > takes, not because of the value it may or may even never have. =
> Any data
> > > > > > > member, even a data member only few people find useful, should =
> at some
> > > > > > > point in its life have a value that those people want to refer =
> to.
> > > > > > > Padding may change randomly or never at all, and you can blot o=
> ver it
> > > > > > > without affecting anyone.
> >
> > > > > > In
> >
> > > > > > struct s {
> > > > > > unsigned foo : 4;
> > > > > > unsigned : 12;
> > > > > > unsigned bas : 16;
> > > > > > };
> >
> > > > > > would you say the data member between foo and bas is there as
> > > > > > padding?
> >
> > > I might, if say I was describing the format of a data packet.
> > > I don't consider it "padding" in the C sense of the word.
> >
> > > > > Since you can't access its value at all (stupid tricks with unsigne=
> d
> > > > > char pointers aside), and that value is therefore irrelevant, yes.
> >
> > > I think the "stupid trick" with unsigned char can't be ignored.
> >
> > > > C trivia question: Is it possible to access the value of an unname=
> d
> > > > bit-field in a way that's portable and not implementation dependent?
> >
> > > no. Its very position is implementation defined
> >
> > > > 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:
> >
> > > surprise me
> >
> > > > 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 */
> >
> > > ...and invoke Undefined Behaviour. You've replaced IB with UB.
> >
> > No, this is defined behavior, not undefined behavior.
> > Please see 6.5.2.3 p 5
>
> what's the section titled, "Structure and Union Members"?
> Or could you quote it? I don't have an ISO standard handy.
>
> This is the "common initial sequence" bit? Interesting.

Yes, the common initial sequence guarantee. Here is the text of
paragraph 5:

One special guarantee is made in order to simplify the use
of unions: if a union contains several structures that
share a common initial sequence (see below), and if the
union object currently contains one of these structures, it
is permitted to inspect the common initial part of any of
them anywhere that a declaration of the complete type of the
union is visible. Two structures share a common initial
sequence if corresponding members have compatible types
(and, for bit-fields, the same widths) for a sequence of one
or more initial members.