My C Program Crashed the Terminal :(

As part of my homework assignment (due tonight!), I have to write two versions of the standard library function strncpy(), one using array's and one using pointers.

The strncpy() function basically takes two arguments, *src and *dest, and copies n number of bytes from *src to *dest.


// Function declarations
char *mystrncpy(char *dest, const char *src, size_t n);

    char a[] = "this is a string";
    char b[50];

    mystrncpy(b, a, 400); // here is the problem
    printf("%sn", b);

    return 0;

// My attempt to replicate the strncpy() function with pointers
char *mystrncpy(char *dest, const char *src, size_t n)
    int i = 0;
    while (i <= n) {
        *dest = *src;

While testing this pointer version of the function, I passed a much larger size (400) to the function than had been allocated for the destination variable (b[50]).

eris:hw3 raam$ gcc problem8.c -o problem8
eris:hw3 raam$ ./problem8
this is a string
Segmentation fault

Segmentation Fault

There is no better way to tell me my function needs more work than to stick a big "Application quit unexpectedly" message in my face! (And thankfully, my entire iTerm app did not crash.)

I wrote a post a few weeks ago about how eerily close C variables are to the machine, and the way this program crashed further confirms that point. I can't imagine the kinds of nasty things I will be able to do once I learn more advanced C functions. 😀

Write a Comment


  1. Local variables are allocated on the stack. When you write past the end of an array you will trash important data which controls program flow (return address, saved stack pointer, caller’s local vars, etc).

    If you get a little more clever with it, you can cause a program to execute code contained in the string you pass in. You’ve probably heard of this, it’s called a buffer overflow exploit.

  2. Yeah, it’s amazing how many thing I’ve read about (such as buffer overflow exploits) but never fully understood until now.

    For several lectures now the professor has been saying how “the stack” starts in high memory and grows down. At first, this didn’t make sense logically because I was thinking in terms of a glass of water. You fill a glass up, you don’t (and can’t) fill it from the top down.

    But when he finally started talking about memory allocation and how you can request more memory for your program (using malloc() or something similar), it made perfect sense. The computer doesn’t know how much memory you’ll need, so the stack (local variables, etc) starts at the top and grows as needed, while the heap lives at the bottom and grows up.

    It’s incredible how valuable learning C is turning out to be.

  3. For what it’s worth, what you’ve got there is more-or-less in line with the strcpy provided in the GNU suite:

    If the destination string of a strcpy() is not large enough (that is, if the programmer was
    stupid/lazy, and failed to check the size before copying) then anything might happen. Overflowing
    fixed length strings is a favourite cracker technique.

    Also, I’m really glad that I no longer deal with low-to-mid-level languages 🙂

  4. Haha, wow. I don’t know how, but I missed that section of the man page for strcpy() but I guess I don’t feel so bad now about running into that problem. 😛

    I’ve done a lot of stuff in PHP and toyed with some higher-level languages, and I actually *love* the low-levelness of C. I donno, maybe it’s because I’m young and foolish and I still have a lot to learn. 😛