Question about size and memory layout of a Union.

[dspfun]

Hi!

I have stumbled on the following C question and I am wondering wether
the answer is implementation specific or if the answer is always
valid, especially question b).

BRs!

----------------------------------------------------
Following C code runs on a "little endian" machine that has a 32-bit
word alignment for memory access. An unsigned integer is 32 bit long.
struct A
{
unsigned int a1;
char a2;
};

union B
{
unsigned char d[10];
struct A a;
};
union B b;

memset((void*)&b, 0xff, sizeof(b));
memset((void*)&(b.a), 0, sizeof(b.a));
b.a.a1 = 0x01020304;
b.a.a2 = 0x5;

a) What is the size of variable b?
Answer: 12
b) Write down the memory dump of b in the form of hex numbers,
starting from lower address.
Answer: 0x4 0x3 0x2 0x1 0x5 0x0 0x0 0x0 0xff 0xff 0xff 0xff
----------------------------------------------------

[Richard Heathfield]

dspfun said:

Hi!

I have stumbled on the following C question and I am wondering wether
the answer is implementation specific or if the answer is always
valid, especially question b).

It's implementation-specific in both cases.

Following C code runs on a "little endian" machine that has a 32-bit
word alignment for memory access. An unsigned integer is 32 bit long.
struct A
{
unsigned int a1;
char a2;
};

The implementation can put an arbitrary number of padding bytes after any
structure member. There's nothing to stop the implementation putting 32
bits of padding between a1 and a2 if it likes.

>
union B
{
unsigned char d[10];
struct A a;
};
union B b;

memset((void*)&b, 0xff, sizeof(b));
memset((void*)&(b.a), 0, sizeof(b.a));

The cast is unnecessary in both cases.

b.a.a1 = 0x01020304;
b.a.a2 = 0x5;

a) What is the size of variable b?

sizeof b

Answer: 12

<shrugMaybe, but not necessarily, whereas sizeof b is definitely right.

b) Write down the memory dump of b in the form of hex numbers,
starting from lower address.

unsigned char *p = (unsigned char *)*b;
size_t n = sizeof b;
while(n--)
{
printf(" 0x%x", *p++);
}
putchar('\n');

Answer: 0x4 0x3 0x2 0x1 0x5 0x0 0x0 0x0 0xff 0xff 0xff 0xff

Maybe, but maybe not. The Standard does not guarantee this.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[dspfun]

On 15 Okt, 09:21, Richard Heathfield <[e-mail]:

It's implementation-specific in both cases.

Thank you for great answers!

Just to make sure:
The question itself specifies that the machine is little endian and
has a 32-bit word alignment for memory access and an unsigned integer
is 32 bit long. Does that make the answers explicit/valid, or are the
answers still implementation specific?

BRs!

[Richard Heathfield]

dspfun said:

On 15 Okt, 09:21, Richard Heathfield <[e-mail]:

>It's implementation-specific in both cases.

Thank you for great answers!

Just to make sure:
The question itself specifies that the machine is little endian and
has a 32-bit word alignment for memory access and an unsigned integer
is 32 bit long. Does that make the answers explicit/valid, or are the
answers still implementation specific?

Well, your answers demonstrate one reasonable response to the code by an
implementation on such a platform. Possibly the *most* reasonable
response. Unfortunately for the purpose of your question, the C Standard
does not require that implementations must be reasonable; it requires only
that they act in accordance with the Standard. And it is certainly
possible - even easy - to imagine answers different to yours that are
still in accordance with the Standard, even on such hardware as you
specify.

Let's just say that I'd be - um... aha! - surprised to learn that an
implementation that targets your platform does so in a way different to
what you clearly expect, unless specifically instructed so to do.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Martien Verbruggen]

On Mon, 15 Oct 2007 07:21:47 +0000,
Richard Heathfield <rj*@see.sig.invalidwrote:

dspfun said:

>union B
{
unsigned char d[10];
struct A a;
};
union B b;

>b) Write down the memory dump of b in the form of hex numbers,
starting from lower address.

unsigned char *p = (unsigned char *)*b;

ITYM

unsigned char *p = (unsigned char *)&b;

Martien
--
|
Martien Verbruggen | Freudian slip: when you say one thing but
| mean your mother.
|

[Richard Heathfield]

Martien Verbruggen said:

On Mon, 15 Oct 2007 07:21:47 +0000,
Richard Heathfield <rj*@see.sig.invalidwrote:

>dspfun said:

>>union B
{
unsigned char d[10];
struct A a;
};
union B b;

>>b) Write down the memory dump of b in the form of hex numbers,
starting from lower address.

unsigned char *p = (unsigned char *)*b;

ITYM

unsigned char *p = (unsigned char *)&b;

Er, yes, I do, don't I? :-)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[dspfun]

Just to make sure:

The question itself specifies that the machine is little endian and
has a 32-bit word alignment for memory access and an unsigned integer
is 32 bit long. Does that make the answers explicit/valid, or are the
answers still implementation specific?

Well, your answers demonstrate one reasonable response to the code by an
implementation on such a platform. Possibly the *most* reasonable
response. Unfortunately for the purpose of your question, the C Standard
does not require that implementations must be reasonable; it requires only
that they act in accordance with the Standard. And it is certainly
possible - even easy - to imagine answers different to yours that are
still in accordance with the Standard, even on such hardware as you
specify.

Thanks again for your answers!

Could you give some "easy" examples of how the answers could be
different while still running on the specified hardware?

BRs!

[Mark McIntyre]

On Thu, 18 Oct 2007 04:26:19 -0700, in comp.lang.c , dspfun
<ds****@hotmail.comwrote:

Just to make sure:
The question itself specifies that the machine is little endian and
has a 32-bit word alignment for memory access and an unsigned integer
is 32 bit long. Does that make the answers explicit/valid, or are the
answers still implementation specific?

Well, your answers demonstrate one reasonable response to the code by an
implementation on such a platform. Possibly the *most* reasonable
response. Unfortunately for the purpose of your question, the C Standard
does not require that implementations must be reasonable; it requires only
that they act in accordance with the Standard. And it is certainly
possible - even easy - to imagine answers different to yours that are
still in accordance with the Standard, even on such hardware as you
specify.

Thanks again for your answers!

Could you give some "easy" examples of how the answers could be
different while still running on the specified hardware?

Many compilers offer a pragma "pack" which alters how memory is laid
out in unions and structs.
A 16-bit compiler might give a different answer from a 32-bit compiler
on the same hardware (ISTR that MSVC 1.5 and MSVC 4.0 managed this).

Further discussion is probably offtopic here.


--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[J. J. Farrell]

On Oct 18, 12:26 pm, dspfun <[e-mail]:

Just to make sure:
The question itself specifies that the machine is little endian and
has a 32-bit word alignment for memory access and an unsigned integer
is 32 bit long. Does that make the answers explicit/valid, or are the
answers still implementation specific?

Well, your answers demonstrate one reasonable response to the code by an
implementation on such a platform. Possibly the *most* reasonable
response. Unfortunately for the purpose of your question, the C Standard
does not require that implementations must be reasonable; it requires only
that they act in accordance with the Standard. And it is certainly
possible - even easy - to imagine answers different to yours that are
still in accordance with the Standard, even on such hardware as you
specify.

Thanks again for your answers!

Could you give some "easy" examples of how the answers could be
different while still running on the specified hardware?

The compiler might put 37 bytes of padding between the two members of
struct A. That would be an odd thing for it to do, but it would be
perfectly valid and fully compliant with the C Standard.

[dspfun]

Thank you for your answers!

To try to conclude by refering to the sections of the C-standard I
beleive question a) above is implementation defined due to the
following text in the C-standard:
---------------------------------------------
6.5.3.4 The sizeof operator
4. The value of the result is implementation-defined, and its type (an
unsigned integer type) is size_t, defined in <stddef.h(and other
headers).
---------------------------------------------

Question b) is implementation defined due to the following text in the
C-standard:
----------------------------------------------
6.2.6.1 General
6 When a value is stored in an object of structure or union type,
including in a member object, the bytes of the object representation
that correspond to any padding bytes take unspecified values.42) The
value of a structure or union object is never a trap representation,
even though the value of a member of the structure or union object may
be
a trap representation.

7 When a value is stored in a member of an object of union type, the
bytes of the object representation that do not correspond to that
member but do correspond to other members take unspecified values.

6.7.2.1 Structure and union specifiers
15. There may be unnamed padding at the end of a structure or union.
----------------------------------------------

Do you agree?

BRs!