> Hi all,
>
> Another episode in the ongoing "Peter learns something new about C" =20=
> drama. John came to office hours today and we hacked a rough =20
> implementation of SDBM together. As part of that, we had "move =20
> around" these kinds of structures:
>
> struct entry {
> char key[MAX_KEY_LENGTH];
> char value[MAX_VALUE_LENGTH];
> };
>
> Remember how in C you cannot assign arrays? So if we have
>
> int a[10];
> int b[10];
>
> we *cannot* write an assignment like
>
> a =3D b;
>
> since the compiler will complain about the types not matching up. =20
> We can, however, assign structures. So if we have
>
> struct point {
> int x;
> int y;
> } a, b;
>
> we *can* write
>
> a =3D b;
>
> and what will happen is that the components of the structure get =20
> assigned. Now imagine my surprise when it comes to the struct entry =20=
> defined above. If you have
>
> struct entry a;
> struct entry b;
>
> you *can* write
>
> a =3D b;
>
> even though the elements of the structure are themselves arrays. =20
> Fascinating! Why? Well, since assignments between arrays are not =20
> allowed, you cannot explain assignment between structs by =20
> assignment of their fields alone! In a saner language the same =20
> rules would apply to all arrays, whether they are part of a struct =20
> or not. But in C that's apparently not the case.
>
> So far I've been unable to find a good explanation for this =20
> behavior. In fact, it's *so* inconsistent that it never even =20
> crossed my mind to try it before John asked "Why don't we just =20
> assign the structs instead of using two different strcpy() calls?" =20
> in office hours today. If anyone here finds a good explanation, =20
> please do share. :-)
>
> Cheers,
> Peter
>
> PS: And by "good explanation" I don't mean "well the C compiler =20
> does a memcpy() for structs without even looking at the components" =20=
> since that's just an implementation choice but not essential to the =20=
> language.