Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Struct assignment

Reply
Thread Tools

Struct assignment

 
 
Grey Alien
Guest
Posts: n/a
 
      06-30-2007
If I have the ff struct:

struct A
{
unsigned int i;
char s[LONG_ENOUGH];
} a, b;


And use them in code like this:

a.i = 42 ;
strcpy(a.s,"test");

b.i = 100 ;

b = a ;

at this point, a (bitwise?) copy of a is made to b. Question is:

1). is b.s now ptr to a.s ? (I think so)
If so, what happens if for instance variable 'a' goes out of scope (?)

2). Does the compiler generate an implicit "memcpy" or "memmove" behind
the scenes when it sees an assignment like this (to avoid dangling ptrs)?
 
Reply With Quote
 
 
 
 
Malcolm McLean
Guest
Posts: n/a
 
      06-30-2007

"Grey Alien" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> If I have the ff struct:
>
> struct A
> {
> unsigned int i;
> char s[LONG_ENOUGH];
> } a, b;
>
>
> And use them in code like this:
>
> a.i = 42 ;
> strcpy(a.s,"test");
>
> b.i = 100 ;
>
> b = a ;
>
> at this point, a (bitwise?) copy of a is made to b. Question is:
>
> 1). is b.s now ptr to a.s ? (I think so)
> If so, what happens if for instance variable 'a' goes out of scope (?)
>
> 2). Does the compiler generate an implicit "memcpy" or "memmove" behind
> the scenes when it sees an assignment like this (to avoid dangling ptrs)?
>

The answer is 2. A structure assignment will cause a call to memcpy to be
made, or equivalent code emitted if the structure is small enough to make
this wasteful and the compiler is clever.
However if structures contain pointers then the values of the pointers are
overwritten. So you have to be extremely careful not to orphan memory or
create peculiar bugs with aliases.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm



 
Reply With Quote
 
 
 
 
Flash Gordon
Guest
Posts: n/a
 
      06-30-2007
Grey Alien wrote, On 30/06/07 17:43:
> If I have the ff struct:
>
> struct A
> {
> unsigned int i;
> char s[LONG_ENOUGH];
> } a, b;
>
>
> And use them in code like this:
>
> a.i = 42 ;
> strcpy(a.s,"test");
>
> b.i = 100 ;
>
> b = a ;
>
> at this point, a (bitwise?) copy of a is made to b.


It is not a bitwise copy, it is a copy of all the elements in the struct.

> Question is:
>
> 1). is b.s now ptr to a.s ? (I think so)


Since b.s was not defined as a pointer, what makes you think an
assignment could magically transform it from being an array in to being
a pointer? You need to read section 6 of the comp.lang.c FAQ at
http://c-faq.com/ specifically the questions dealing with whether
pointers and arrays are the same thing.

> If so, what happens if for instance variable 'a' goes out of scope (?)
>
> 2). Does the compiler generate an implicit "memcpy" or "memmove" behind
> the scenes when it sees an assignment like this (to avoid dangling ptrs)?


It is very rare for C to do things behind your back. Had there been
pointers in your struct (which there were not) then after the assignment
they would point to the same place as they point in the original struct,
and when that place is no longer valid (an automatic that goes out of
scope, for example) the pointers are no longer valid.
--
Flash Gordon
 
Reply With Quote
 
Thomas Lumley
Guest
Posts: n/a
 
      06-30-2007
On Jun 30, 9:43 am, Grey Alien <(E-Mail Removed)> wrote:
> If I have the ff struct:
>
> struct A
> {
> unsigned int i;
> char s[LONG_ENOUGH];
>
> } a, b;
>
> And use them in code like this:
>
> a.i = 42 ;
> strcpy(a.s,"test");
>
> b.i = 100 ;
>
> b = a ;
>
> at this point, a (bitwise?) copy of a is made to b.
> Question is:
>
> 1). is b.s now ptr to a.s ? (I think so)


I think you are confusing arrays and pointers. Since a.s is an array,
a.s[0] to a.s[LONG_ENOUGH-1] are actually stored in the structure and
are copied by the assignment.

If a.s were just a pointer to memory allocated elsewhere the
assignment would just copy the pointer.

> 2). Does the compiler generate an implicit "memcpy"
> or "memmove" behind the scenes when it sees an
> assignment like this (to avoid dangling ptrs)?


There is an explicit copy since a.s is an array. If a.s
were a pointer there would not be an implicit copy, and
Bad Things such as dangling pointers could result.

-thomas

 
Reply With Quote
 
Serve Lau
Guest
Posts: n/a
 
      06-30-2007

"Flash Gordon" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)-gordon.me.uk...
> Grey Alien wrote, On 30/06/07 17:43:
>> If I have the ff struct:
>>
>> struct A
>> {
>> unsigned int i;
>> char s[LONG_ENOUGH];
>> } a, b;
>>
>>
>> And use them in code like this:
>>
>> a.i = 42 ;
>> strcpy(a.s,"test");
>>
>> b.i = 100 ;
>>
>> b = a ;
>>
>> at this point, a (bitwise?) copy of a is made to b.

>
> It is not a bitwise copy, it is a copy of all the elements in the struct.
>
> > Question is:
>>
>> 1). is b.s now ptr to a.s ? (I think so)

>
> Since b.s was not defined as a pointer, what makes you think an assignment
> could magically transform it from being an array in to being a pointer?
> You need to read section 6 of the comp.lang.c FAQ at http://c-faq.com/
> specifically the questions dealing with whether pointers and arrays are
> the same thing.


Its easy to see where the confusion comes from. There are situations where
pointers degenerate into pointers , the OP probably had that in mind



 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      06-30-2007
Serve Lau wrote, On 30/06/07 19:53:
> "Flash Gordon" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)-gordon.me.uk...
>> Grey Alien wrote, On 30/06/07 17:43:


<snip>

>>> 1). is b.s now ptr to a.s ? (I think so)

>> Since b.s was not defined as a pointer, what makes you think an assignment
>> could magically transform it from being an array in to being a pointer?
>> You need to read section 6 of the comp.lang.c FAQ at http://c-faq.com/
>> specifically the questions dealing with whether pointers and arrays are
>> the same thing.

>
> Its easy to see where the confusion comes from. There are situations where
> pointers degenerate into pointers , the OP probably had that in mind


In my opinion it is only easy to confuse arrays and pointers if it is
badly taught. If arrays and pointers are taught as fundamentally
different concepts and *then* the way array names degenerate to pointers
to the first element is explained there will not be anything like the
problems. In one-to-one sessions I've been able to explain the basics of
arrays pointers to non-computer people in minutes (I needed to so I
could explain approximately what was the cause of a problem), although I
did not go on to how things are done in C.
--
Flash Gordon
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      06-30-2007
Serve Lau said:

<snip>

> Its easy to see where the confusion comes from. There are situations
> where pointers degenerate into pointers ,


Pointers always degenerate into pointers.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      06-30-2007
Flash Gordon <(E-Mail Removed)> writes:
> Grey Alien wrote, On 30/06/07 17:43:
>> If I have the ff struct:
>> struct A
>> {
>> unsigned int i;
>> char s[LONG_ENOUGH];
>> } a, b;
>> And use them in code like this:
>> a.i = 42 ;
>> strcpy(a.s,"test");
>> b.i = 100 ;
>> b = a ;
>> at this point, a (bitwise?) copy of a is made to b.

>
> It is not a bitwise copy, it is a copy of all the elements in the struct.


Yes -- and that can be, and commonly is, implemented as a bitwise copy
of the struct.

Suppose there's a gap between the members "i" and "s". After the
assignment "b = a;", the gaps in "a" and "b" may or may not have the
same contents. The assignment can be done either as a bitwise copy or
by copying the members one-by-one, leaving any gaps alone.

99% of the type, this doesn't matter because you're never going to
look at what's in the gaps anyway.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      06-30-2007
Richard Heathfield wrote, On 30/06/07 20:56:
> Serve Lau said:
>
> <snip>
>
>> Its easy to see where the confusion comes from. There are situations
>> where pointers degenerate into pointers ,

>
> Pointers always degenerate into pointers.


No they don't, they stay as pointers

Knowing what Serve Lau must have intended I read it as "where arrays
degenerate...".
--
Flash Gordon
 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      06-30-2007
Keith Thompson wrote, On 30/06/07 21:30:
> Flash Gordon <(E-Mail Removed)> writes:
>> Grey Alien wrote, On 30/06/07 17:43:
>>> If I have the ff struct:
>>> struct A
>>> {
>>> unsigned int i;
>>> char s[LONG_ENOUGH];
>>> } a, b;
>>> And use them in code like this:
>>> a.i = 42 ;
>>> strcpy(a.s,"test");
>>> b.i = 100 ;
>>> b = a ;
>>> at this point, a (bitwise?) copy of a is made to b.

>> It is not a bitwise copy, it is a copy of all the elements in the struct.

>
> Yes -- and that can be, and commonly is, implemented as a bitwise copy
> of the struct.
>
> Suppose there's a gap between the members "i" and "s". After the
> assignment "b = a;", the gaps in "a" and "b" may or may not have the
> same contents. The assignment can be done either as a bitwise copy or
> by copying the members one-by-one, leaving any gaps alone.
>
> 99% of the type, this doesn't matter because you're never going to
> look at what's in the gaps anyway.


Where there are multiple representations for the same value the
representation could change. It is important for the OP to know this
IMHO so that s/he does not assume that memcmp can be used safely.
--
Flash Gordon
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Can *common* struct-members of 2 different struct-types, that are thesame for the first common members, be accessed via pointer cast to either struct-type? John Reye C Programming 28 05-08-2012 12:24 AM
Rationale for struct assignment and no struct comparison Noob C Programming 25 12-09-2009 08:56 AM
Assignment operator self-assignment check Chris C++ 34 09-26-2006 04:26 AM
Augument assignment versus regular assignment nagy Python 36 07-20-2006 07:24 PM
struct my_struct *p = (struct my_struct *)malloc(sizeof(struct my_struct)); Chris Fogelklou C Programming 36 04-20-2004 08:27 AM



Advertisments