Re: padding?

Nick Keighley <nick_keighley_nospam@xxxxxxxxxxx> writes:

On 9 July, 11:30, Tim Rentsch <t...@xxxxxxxxxxxxxxxxxxx> wrote:
Nick Keighley <nick_keighley_nos...@xxxxxxxxxxx> writes:
On 25 June, 18:20, Tim Rentsch <t...@xxxxxxxxxxxxxxxxxxx> wrote:
ralt...@xxxxxxxxx (Richard Bos) writes:
Tim Rentsch <t...@xxxxxxxxxxxxxxxxxxx> wrote:
ralt...@xxxxxxxxx (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.

.

Relevant Pages

  • Re: Undefined behaviour
    ... The stuff you are quoting does NOT appear in the C99 standard. ... One special guarantee is made in order to simplify the use of unions: ... object currently contains one of these structures, it is permitted to inspect the common ... Two structures share a common initial sequence if corresponding members have ...
    (comp.lang.cpp)
  • Re: type punning question...
    ... use of a union type is suggested. ... if a union contains several structures that share a common ... _common initial sequence_ if corresponding members have compatible ...
    (comp.std.c)
  • A question about unions (connected to an issue from c.l.c)
    ... union contains several structures that share a common initial sequence (see ...
    (comp.std.c)
  • Re: How to extract bytes from a long?
    ... >When both variables in the union starts at the same address, ... > several structures that share a common initial sequence (see ... > share a common initial sequence if corresponding members ...
    (comp.lang.c)
  • Re: Cohens paper on byte order
    ... > depend on the applicability of the common hex notation. ... bit sequence, there is a bit-order-within-unit issue for ... *any* multibit storage units, not just octet units, and ... fact true of almost all data storage and transmission ...
    (sci.crypt)