strcpy Question

[herrcho]

#include <stdio.h>
#include <string.h>

int main()
{
char *imsip;

strcpy(imsip, "archie");
return 0;
}

the above code causes error which i expected.. as the object imsip is
not initalized.
But the below one executes alright..

#include <stdio.h>
#include <string.h>

int main()
{
struct msg
{
char p1[30];
char *p2;
} myptrs;

strcpy(myptrs.p1, "Wonderful day");
strcpy(myptrs.p2, "Beautiful Day");

puts(myptrs.p1);
puts(myptrs.p2);
return 0;
}

I have no idea how come the second one executes alright..

Thanks in advance..

 

[Bertrand Mollinier Toublet]

#include <stdio.h>
#include <string.h>

int main()
{
char *imsip;

strcpy(imsip, "archie");
return 0;
}

the above code causes error which i expected.. as the object imsip is
not initalized.
But the below one executes alright..

#include <stdio.h>
#include <string.h>

int main()
{
struct msg
{
char p1[30];
char *p2;
} myptrs;

strcpy(myptrs.p1, "Wonderful day");
strcpy(myptrs.p2, "Beautiful Day");

puts(myptrs.p1);
puts(myptrs.p2);
return 0;
}

I have no idea how come the second one executes alright..

To dereference and otherwise try to access the memory pointed by an
uninitialized pointer is Undefined Behaviour. Undefined Behaviour
includes behaving (apparently) correctly.

On some facetious platforms, such as the DS9k, it also includes
systematically behaving the opposite of what the user expects. I know.
This is very advances technology (able of mind reading, etc), which the
world isn't ready for. That's why you only find DS9ks in Area 51...

 

[Kris Wempa]

Since strcpying into an uninitialized/unallocated pointer is undefined, you
are not guaranteed of the results. Either point the pointer to some
allocated memory or declare another character array with adequate space so
you won't have this problem.

 

[Mark McIntyre]

struct msg
{
char p1[30];
char *p2;
} myptrs;

strcpy(myptrs.p1, "Wonderful day");
strcpy(myptrs.p2, "Beautiful Day");

I have no idea how come the second one executes alright..

By bad luck. By chance, there happened to be some spare memory after
the declaration of p2.

 

[John Roussos]

But the below one executes alright..

#include <stdio.h>
#include <string.h>

int main()
{
struct msg
{
char p1[30];
char *p2;
} myptrs;

strcpy(myptrs.p1, "Wonderful day");
strcpy(myptrs.p2, "Beautiful Day");

puts(myptrs.p1);
puts(myptrs.p2);
return 0;
}

I have no idea how come the second one executes alright..

Thanks in advance..

Pointer p2 uses allocated memory from p1.
Try 2 bigger strings and you'll see that they overlap...
e.g.
strcpy(myptrs.p1, "Wonderful day ...bla...bla...bla...");
strcpy(myptrs.p2, "Beautiful Day ...bla...bla...bla...");
printf("%s\n",myptrs.p1);
printf("%s\n",myptrs.p2);

 

[CBFalconer]

#include <stdio.h>
#include <string.h>

int main()
{
char *imsip;

strcpy(imsip, "archie");
return 0;
}

the above code causes error which i expected.. as the object
imsip is not initalized.
But the below one executes alright..

#include <stdio.h>
#include <string.h>

int main()
{
struct msg
{
char p1[30];
char *p2;
} myptrs;

strcpy(myptrs.p1, "Wonderful day");
strcpy(myptrs.p2, "Beautiful Day");

puts(myptrs.p1);
puts(myptrs.p2);
return 0;
}

I have no idea how come the second one executes alright..

To dereference and otherwise try to access the memory pointed
by an uninitialized pointer is Undefined Behaviour. Undefined
Behaviour includes behaving (apparently) correctly.

On some facetious platforms, such as the DS9k, it also includes
systematically behaving the opposite of what the user expects.
I know. This is very advances technology (able of mind reading,
etc), which the world isn't ready for. That's why you only find
DS9ks in Area 51...

You are leaving the OP even more confused. Not only do the
pointers imsip and myptrs.p2 need to be initialized, they have to
be initialized to point to sufficient memory to hold the strings
to be copied into them (which is at least one greater than the
length of such string). The usual method is via "ptr =
malloc(sizeneeded);" and checking the result is non NULL. However
the space need not be allocated by malloc, it may be function
scope or file scope declared arrays (usually called local or
global). The difference is how to release that memory later.

To the OP: The second one DOES NOT execute alright, it only
appears that way on your particular system. One possibility for
undefined behavior is to apparently succeed.

 

[Mac]

But the below one executes alright..

#include <stdio.h>
#include <string.h>

int main()
{
struct msg
{
char p1[30];
char *p2;
} myptrs;

strcpy(myptrs.p1, "Wonderful day");
strcpy(myptrs.p2, "Beautiful Day");

puts(myptrs.p1);
puts(myptrs.p2);
return 0;
}

I have no idea how come the second one executes alright..

Thanks in advance..

Pointer p2 uses allocated memory from p1.

What gives you that idea? It has already been pointed out that the code
invokes Undefined Behavior (UB) so why do you try to rationalize what is
happening?

Or, better yet, what section in the standard makes you think that myptrs.p2
points just beyond myptrs.p1 in this code?

Try 2 bigger strings and you'll see that they overlap...
e.g.
strcpy(myptrs.p1, "Wonderful day ...bla...bla...bla...");
strcpy(myptrs.p2, "Beautiful Day ...bla...bla...bla...");
printf("%s\n",myptrs.p1);
printf("%s\n",myptrs.p2);

Mac
--

 

[Victor]

The unitialized (by you) pointers will, nevertheless, have some
initial value. For whatever reason, in the first code snippet, imsip
has a value that causes a memory violation. In the second example,
myptrs.p2 falls within the valid memory range for the process. You
should try printing out the values of the unitialized pointers and
verify that they are "initialized" to different values.

This is an excellent example of undefined behaviour.

 

[Mike Wahler]

The unitialized (by you) pointers will, nevertheless, have some
initial value.

No, not from the language perspective they don't.

For whatever reason, in the first code snippet, imsip
has a value that causes a memory violation.

Yes, this is a concrete example of one of
theoretically infinite possiblities.

In the second example,
myptrs.p2 falls within the valid memory range for the process. You
should try printing out the values of the unitialized pointers and
verify that they are "initialized" to different values.

Evaluating an uninitialized object produces undefined
behavior. The results *cannot* be used to draw
*any* conclusions. They verify nothing. (e.g. the result
could vary every time, even on the same system).

This is an excellent example of undefined behaviour.

Sure is.

-Mike