char s[] = "Str1";
    char t[] = "Longer string";

and a pointer to char for each, which points to the first char in the
array:

    char *p = s;
    char *q = t;

I was wondering why it seems I can store more chars onto the end of s.
Here is a routine that
concatenates t onto the end of s using pointer arithmetic to access the
array elements:

    int i, j = 0;

    while ( *(p+i) != '\0') i++;     /* set i to width of s */
    while ( *(p+i++) = *(q+j++) );  /* copy t into s */

Why doesn't this cause a segmentation fault?  I thought that if I tried
to access p beyond the \0 in s,
especially here since im assigning it a value, that I would get a
segmentation fault.  Why is it that
I can store values into memory locations that I have not set aside
storage for?  What is going on in
memory and in the pointers that allows this to happen?

If someone could give me some insight into this problem I would really
appreciate it.  Some of you
might recognize this as one of the exercises from K&R2.  It is ex.5-3 on
p. 107.

Here is a more complete version of what I was trying:

int main()
{
  char s[] = "Str1";
  char t[] = "Longer string";
  char *p = s;
  char *q = t;
  int i;
  int j;
  i=0; j=0;

  while ( *(p+i) != '\0' )
    i++;  /* set i to width of s */

  while ( *(p+i++) = *(q+j++) )

  printf("s = %s t = %s\n", s, t);

  return 0;

Don't expect to get a segmentation fault the moment you write past the bounds
of a particular object. In fact, don't expect anything at all; it is undefined
behavior.

If you access a random memory location, you might get a segmentation
fault. But, if the random memory locaiton you access just happens to be
allocated by your program everything is just fine. And dandy.

An easy way to test this in the real world is to get five baseballs and a
bat. Go to the mall and drop all the baseballs in random spots. Now,
blindfold yourself, begin screaming (which is optional), and
starting running around swinging the bat. You will find that chances are
you jack somebody up good, but once in a while you'll actually hit one of
your balls. (The baseballs.)

In this case, running off the end of the storage for s probably puts you
into the storage for t, or for some other automatic variable. Something
is most probably allocated continguously with s and you are trouncing it
with the code, but as far as the OS is concerned there's nothing wrong.

extra storage allocated onto the local stack.  Lets just say that in memory,

the beginning of t is at the end of s.  For simplicity, say that s starts at
address
0x0000 and t starts at 0x0100 using byte-addressing.  When I go through the
first while loop, p should point to 0x0004 because it doesn't count the null

character.  The first time through the second while copies the data at
0x0100
into 0x0005, the second time through copies 0x0101 into 0x0006, and so on.
The reason there is no segfault is because there is extra room on the stack
that is not allocated by any variable.

But say t was more than 0xFF (256) bytes.  Once I try to copy something
into 0x0100 then I get a segmentation fault, if I hadn't trounced over some
other variable's storage first.  Is this where the undefined behavior comes
from?  Is there a better way to write this code so that I can avoid all
possible
segmentation faults or undefined behavior?  Allocating enough storage
for a character array comes to mind, but is there any other way to do it?

The reason it is called undefined behaviour is because the C standard does
not specify how the memory is defined, therefore one implementation may be
diferent from another, it is not possible to say then how the OS will
behave. Behaviour is undefined.

Try writing code with bounds checking to see if you are at the end of the
array. If you want to copy the first elements of the longer array over the
smaller then test using strlen(s) so you could have

/* Not tested. */
for(i=0;i<(strlen(s)-1);i++)
{
    s[i] = t[i];

...

The result of what you are doing is not guaranteed to be a
segmentation fault. It is "undefined behavior". Can be anything
from not causing any obvious problems to crashing your system.

Your compiler, which got only a pointer without any information
on how much memory is allocated for it, cannot give an error
when you do it. Your runtime system may give an error, but not
necessarily.

You need to make sure this will not happen. That is one painful
thing in C.

- Umesh

--