doubt in struct assignment

[subramanian]

Consdier the following program:

#include <stdio.h>

struct typeRecord {
int id;
char str[100];
} records[] = {
{0, "zero"},
{1, "one"},
{2, "two"},
{3, "three"},
{4, "four"},
{5, "five"},
{6, "six"},
{7, "seven"},
{8, "eight"},
{9, "nine"}
};
int main(void)
{
struct typeRecord rec1 = {10, "ten"};
int i;

for (i = 0; i < 10; ++i)
{
rec1 = records[i];
printf("%d %s\n", rec1.id, rec1.str);
}

return 0;
}

The above program produces the following output in both gcc and VC++.

0 zero
1 one
2 two
3 three
4 four
5 five
6 six
7 seven
8 eight
9 nine

My Doubt:
--------------
character arrays cannot be assigned directly. However the above output
shows that if character array is a member of a structure, the
assignment of structures produces copying of strings as if copied
using strcpy. Is this the expected behaviour of structure assignment ?

[Ian Collins]

subramanian wrote:

>
My Doubt:
--------------

(Question)

character arrays cannot be assigned directly. However the above output
shows that if character array is a member of a structure, the
assignment of structures produces copying of strings as if copied
using strcpy. Is this the expected behaviour of structure assignment ?

Structures are copied byte for byte, the types of the members does not
matter. If a structure is 100 bytes long, 100 bytes are copied.

--
Ian Collins.

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Ian Collins wrote:

subramanian wrote:

My Doubt:
--------------

(Question)

character arrays cannot be assigned directly. However the above output
shows that if character array is a member of a structure, the
assignment of structures produces copying of strings as if copied
using strcpy. Is this the expected behaviour of structure assignment ?

Structures are copied byte for byte, the types of the members does not
matter. If a structure is 100 bytes long, 100 bytes are copied.

The behaviour of the original code is as expected, as you point out,
but the reason is not necessarily correct. Padding bytes need not be
copied, and are not always copied. The reason array assignment doesn't
work is because in most contexts, array names are converted to
pointers to the array's first element, so

int a1[4], a2[4];
int main(void)
{
a1 = a2;
}

is equivalent to

int a1[4], a2[4];
int main(void)
{
&a1[0] = &a2[0];
}

which makes no sense. There is no such problem for structures, even if
they contain array members. It could have been allowed without too
many technical problems, but wasn't, probably because for simplicity,
compilers already didn't support array assignment before C was
standardised, and afterwards, there was not enough value in adding it.

[subramanian]

On Feb 17, 12:22Â*pm, "Harald van Dijk" <[e-mail]:

The behaviour of the original code is as expected, as you point out,
but the reason is not necessarily correct. Padding bytes need not be
copied, and are not always copied.

Kindly clarify the following:

What is meant by padding of bytes ?

If padding bytes are not copied, will it affect the structure members
from being copied correctly?

[santosh]

subramanian wrote:

On Feb 17, 12:22 pm, "Harald van Dijk" <[e-mail]:

The behaviour of the original code is as expected, as you point out,
but the reason is not necessarily correct. Padding bytes need not be
copied, and are not always copied.

Kindly clarify the following:

What is meant by padding of bytes ?

It's not "padding of bytes". It's padding bytes. Padding bytes are
dummy bytes which may be inserted between the members of a struct
object in memory. It's mainly done to honour any hardware alignment
requirements and to speed up the access of the structure object. It's
transparent to the programmer.

If padding bytes are not copied, will it affect the structure members
from being copied correctly?

No, that's something the compiler will take care of. It'll vary from
compiler to compiler and even compilation to compilation with the same
compiler. Once again, any changes, if any, will be transparent to the
programmer and it "Just Works".

PS. Even scalar objects like int or long are allowed to have padding
bits, but in practise this is much rarer than padding bytes for
structures.

[Keith Thompson]

"santosh" <sa*********@gmail.comwrites:

subramanian wrote:

>On Feb 17, 12:22 pm, "Harald van Dijk" <[e-mail]:

The behaviour of the original code is as expected, as you point out,
but the reason is not necessarily correct. Padding bytes need not be
copied, and are not always copied.

Kindly clarify the following:

What is meant by padding of bytes ?

It's not "padding of bytes". It's padding bytes. Padding bytes are
dummy bytes which may be inserted between the members of a struct
object in memory. It's mainly done to honour any hardware alignment
requirements and to speed up the access of the structure object. It's
transparent to the programmer.

>If padding bytes are not copied, will it affect the structure members
from being copied correctly?

No, that's something the compiler will take care of. It'll vary from
compiler to compiler and even compilation to compilation with the same
compiler. Once again, any changes, if any, will be transparent to the
programmer and it "Just Works".

Yes, theoretically padding bytes can vary from compilation to
compilation with the same compiler, but in practice it's likely to be
consistent. Storing data by writing structures directly to files is
often a bad idea, but you can usually get away with it as long as you
use the same implementation. If this weren't the case, you might
recompile your program and lose the ability to read the data files you
just created.

But some compilers do support compile-time options that can change
data layout.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.