[comp.lang.c] Is simple assignment allowed with structs

aj3u@wilbury.ra.cs.virginia.edu (Asim Jalis) (03/31/91)

My compiler accepts the following program:

struct s 
{ int x; 
  int y 
} a,b;
main() 
{ a.x = 10 ; a.y = 29;
  print(a);print(b);
  b = a; 
  print(a);print(b);
  a.x = 200 ; a.y = 34;
  print(a);print(b);
}

The assignment from all appearances seems to copy both the fields of a
to b.  My question is, is such assignment legal.  Can I expect other
compilers to support this?  Or should I explicitly assign the fields
to ensure portability.  

I tried adding two structs and that did not work.

Comments?  Suggestions?

gwyn@smoke.brl.mil (Doug Gwyn) (03/31/91)

In article <AJ3U.91Mar30161251@wilbury.ra.cs.virginia.edu> aj3u@wilbury.ra.cs.virginia.edu (Asim Jalis) writes:
>The assignment from all appearances seems to copy both the fields of a
>to b.  My question is, is such assignment legal.  Can I expect other
>compilers to support this?  Or should I explicitly assign the fields
>to ensure portability.  

Structure assignment has been an official part of C since around 1978.
While there MAY be some things loosely called "C compilers" that do not
support this, all the current C compilers that I know of do support it.
Since the C standard requires it for conforming implementations, there
should be no future C compilers that do not understand this.

>I tried adding two structs and that did not work.

Of course not.  What would it mean?

avery@netcom.COM (Avery Colter) (04/08/91)

gwyn@smoke.brl.mil (Doug Gwyn) writes:

>>I tried adding two structs and that did not work.

>Of course not.  What would it mean?

Now, of course, there is nothing stopping you from making a little function
to "add" two structs of the same type and return a struct of this type
as the function result; the body of the function would just be field-by-field
simple addition of the parallel field values in the input structs.

The reason assignment works is that structs of the same type are of the same
size in bytes, and all have their fields at the same byte offsets, so that
assignment would just mean copying the range of bytes holding the rvalued
struct into the area holding the lvalued struct.


-- 
  ^     ^ 	Avery Ray Colter    
 /^\___/^\    	avery@netcom.com		{apple|claris}!netcom!avery  
(  o _ o  )   	elfcat@btr.btr.com		{decwrl|mips|sgi}!btr!elfcat
 \  /v\  /      71067.606@compuserve.com	(415) 839-4567
  \_*-*_/
    `-'			Afternoon has gently passed me by.	    - The
  ELFCAT! 		And Evening spreads itself against the sky.   Police

gwyn@smoke.brl.mil (Doug Gwyn) (04/09/91)

In article <1991Apr8.073710.22673@netcom.COM> avery@netcom.COM (Avery Colter) writes:
>gwyn@smoke.brl.mil (Doug Gwyn) writes:
>>>I tried adding two structs and that did not work.
>>Of course not.  What would it mean?
>Now, of course, there is nothing stopping you from making a little function
>to "add" two structs of the same type and return a struct of this type
>as the function result; the body of the function would just be field-by-field
>simple addition of the parallel field values in the input structs.

This is not always possible, for example for pointer members.
Even if it were possible, it may not correctly represent an algebraic
"addition" of the quantities represented by the structures, although
often it would.

>The reason assignment works is that structs of the same type are of the same
>size in bytes, and all have their fields at the same byte offsets, so that
>assignment would just mean copying the range of bytes holding the rvalued
>struct into the area holding the lvalued struct.

No, the reason that structure assignment works is that it was decided
that it had clear, universal semantics and that it would frequently be
useful, so the C language was REVISED to require support for structure
assignment.  The implementation must provide the proper semantics, not
the other way around.

fraser@mullauna.cs.mu.OZ.AU (Fraser Wilson) (04/09/91)

gwyn@smoke.brl.mil (Doug Gwyn) writes:

>In article <1991Apr8.073710.22673@netcom.COM> avery@netcom.COM (Avery Colter) writes:
>>gwyn@smoke.brl.mil (Doug Gwyn) writes:
>>>>I tried adding two structs and that did not work.
>>>Of course not.  What would it mean?
>>Now, of course, there is nothing stopping you from making a little function
>>to "add" two structs of the same type and return a struct of this type
>>as the function result; the body of the function would just be field-by-field
>>simple addition of the parallel field values in the input structs.

>This is not always possible, for example for pointer members.
>Even if it were possible, it may not correctly represent an algebraic
>"addition" of the quantities represented by the structures, although
>often it would.

I think what was meant here is to write a unique addition function for
each struct.  Ie, you would only write meaningful addition functions,
and you wouldn't add pointers together.  So yes, it is always possible.

Fraser.

-----------------------------------------------------------------------------
		  For which of thee is made upon
		      The plan of Long Ago?
		  Tho' Wither W'ere in Sacred Sea
		   The Horn of Death shall blow!

avery@netcom.COM (Avery Colter) (04/18/91)

And so the mindless philosopher asks, "Yes, but WHY was it decided that
simple struct assignment had universal semantics?"

I suggest it was for the reason I stated, that the memory offsets are the
same for all variables of the same type of struct.

-- 
  ^     ^ 	Avery Ray Colter    
 /^\___/^\    	avery@netcom.com		{apple|claris}!netcom!avery  
(  o _ o  )   	elfcat@btr.btr.com		{decwrl|mips|sgi}!btr!elfcat
 \  /v\  /      71067.606@compuserve.com	(415) 839-4567
  \_*-*_/
    `-'			Afternoon has gently passed me by.	    - The
  ELFCAT! 		And Evening spreads itself against the sky.   Police

gwyn@smoke.brl.mil (Doug Gwyn) (04/19/91)

In article <1991Apr18.095803.11624@netcom.COM> avery@netcom.COM (Avery Colter) writes:
>And so the mindless philosopher asks, "Yes, but WHY was it decided that
>simple struct assignment had universal semantics?"

The reasoning is that if you copy all the member values for a structured
object, you have copied the value of the object itself.  Of course there
are situations where this isn't quite the sort of copying that one really
wants, but it is simple, well-defined, and useful.

>I suggest it was for the reason I stated, that the memory offsets are the
>same for all variables of the same type of struct.

No -- while the latter condition happens to be true, I don't see that it
has any particular force as an argument for supporting structure assignment.
("Necessary but not sufficient.")