Floats to chars and chars to floats

[Mark McIntyre]

That's why I mentioned "byte" - where "byte" is defined, either by the
system or by the programmer to be 8-bit.

1) you're still top posting. Thats rude.
2) if you mention some type not defined by the Standard, you need to
define it. You cannot rely on the reader having a system that has a
matching definition.

 

[Ben Hetland]

The wording in C89 about unions indicates that padding is allowed
only at the end of the union: each member of the union is
required to start at the common address.

But this wording doesn't rule out internal padding in the union members.
Consider (assuming sizeof(short)==2 and sizeof(int)==4 for the sake of
discussion):

struct s {
short m1; /* p1==2 */
int m2;
}; /* sizeof(s)==8 ? */
union u {
struct s n1;
int n2; /* p2==4 */
short n3; /* p3==6 */
}; /* sizeof(u)==8 ? */

If for instance alignment requirements are such that each primitive type
must be aligned on a multiple of its size, then I would expect that the
above struct s had an internal padding at "p1" (of 2 bytes as
indicated). Variables of type "struct s" or "union u" would both be
aligned at 4-byte boundaries (its most restrictive member).

So even though the union u still has only padding at its end (of
different sizes, marked as "p2" and "p3" above), then it still contains
an "inherited" internal padding from its n1 member. It would, in fact,
be highly unexpected that it lost this internal padding as soon as it
became the member n1 in union u!

In other words, I would expect that
n2 occupies the storage of m1+p1,
n3 is the same storage as m1,
m2 is the same storage as p2.


And further, assuming that a "#pragma pack(1)" or similar that the
compiler honored was introduced later, before we defined

struct t {
struct s a;
short b;
long c;
};

then I _still_ would be surprised if not the internal padding of struct
s is still present in the member a, even though I would of course not
expect any padding between the other members b and c.


-+-Ben-+-

 

[Peter Nilsson]

The wording in C89 about unions indicates that padding is allowed
only at the end of the union: each member of the union is
required to start at the common address. That's a bit different
than "padding can be put in for any reason", which statement
could be interpreted as indicating that padding could occur
at the beginning.

I didn't intend to imply that padding could be put in anywhere. I meant
that implementations can put 'unnecessary' padding in, if they so
choose.

 

[Peter Nilsson]

Walter Roberson wrote:

I'm trying to think of circumstances under which that would be possible,
that an array of char might require internal padding. It seems somewhat
unlikely, verging on the "Surely that's not allowed by the Standard ??"

It is unlikely, but realise that (implicitly in C90) all union pointers
have the same size and representation. Hence an implementation with
different pointer types[1][2] may choose to pad unions to make the
choice of (internal) pointer type easier (and/or efficient.)[3]

Hmmm, that doesn't feel right to me. It looks to me that you are
conflating alignment and padding. Any particular union type only needs
as much alignment as the most restrictive member, so a pointer to a
union A need not have the same size or representation as a pointer to a
different kind of union B.

Actually, it does. 6.2.5 p26: "All pointers to union types
shall have the same representation and alignment requirements as
each other."

That explicit clause was not a part of C90, AFAIK. But as I hinted at,
it's implied from the fact that you can use incomplete union pointers
in ways that must be well defined for any implementation.

 

[Tim Rentsch]

Tim Rentsch wrote: [snip]

Actually, it does. 6.2.5 p26: "All pointers to union types
shall have the same representation and alignment requirements as
each other."

That explicit clause was not a part of C90, AFAIK. But as I hinted at,
it's implied from the fact that you can use incomplete union pointers
in ways that must be well defined for any implementation.

Sorry, I'd missed that the context of the discussion was C90.