7

I might be stupid and you need to excuse me in that case...but I don't get this. I'm allocating a buffer of 16 chars and then (in a for loop) put in 23(!?) random characters and then printing that stuff out.

What I don't get is how I can put 23 chars into a buffer that is malloc'ed as 16 chars...When I change the loop to 24 characters I get an error though(at least in Linux with gcc)...but why not "earlier" (17 characters should break it...no?)

This is my example code:

#include <stdio.h>
#include <stdlib.h>

int main()
{
    int n;
    char *buf;

    buf = malloc(16 * sizeof(*buf));
    if(buf == NULL) exit(1);

    for(n = 0; n < 22; n++)
    {
        buf[n] = rand()%26+'a';
    }
    buf[n]='\0';

    printf("Random string: %s\n", buf);

    free(buf);
    buf = NULL;

    getchar();
    return 0;
}
  • Probably a duplicate: http://stackoverflow.com/questions/1240970/c-why-do-you-specify-the-size-when-using-malloc http://stackoverflow.com/questions/2336796/weird-behavior-of-malloc – bk1e Feb 28 '10 at 08:41

4 Answers4

6

You are producing an error, but like many bugs it just happens to not be noticed. That's all there is to it.

It might be for one of several reasons - probably that the way the free store is structured, there's slack space between allocations because the system needs (or wants) to keep addresses of allocatable blocks aligned on certain boundaries. So writes a little past your allocated block don't interfere with the free stores data structures, but a little bit further and they do.

It is also quite possible that your bug did corrupt something the free store manager was using, but it just happened to not be actually used in your simple program so the error wasn't noticed (yet).

Michael Burr
  • 333,147
  • 50
  • 533
  • 760
  • 5
    To clarify - the OP is probably used to higher-level languages, where such errors are caught. C is deliberately unsafe, and such behavior in C is called "undefined behavior" by the standard, which means that the code can do anything it pleases. Most of the time, it will do the easiest thing it can, which is to ignore the fact that you're not allowed to write into that space and do it anyway. This is the primary reason C is so hard - there's nothing checking you when you do something wrong. – Chris Lutz Feb 28 '10 at 06:49
3

Most memory allocation strategies round your malloc request up to some quantization value. Often 16 or 32 bytes. That quantization usually happens after the allocator has added in its overhead (used to keep track of the allocated blocks), so it's common to find that you can overrun a malloc by some small number of bytes without doing any actual damage to the heap, especially when the allocation size is odd.

Of course, this isn't something that you want to depend on, it's an implementation detail of the c runtime library, and subject to change without notice.

John Knoeller
  • 33,512
  • 4
  • 61
  • 92
1

The behaviour when you overrun a buffer in C is undefined. So anything may happen including nothing. Specifically C is not required and is designed intentionally not to perform bounds checking.

If you get any runtime error at all, it will generally be because it has been detected and trapped by the operating system, not by the C runtime. And that will only occur if the access encroaches upon memory not mapped to the process. More often it will simply access memory belonging to your process but which may be in use by other memory objects; the behaviour of your program will then depend on what your code does with the invalid data.

Clifford
  • 88,407
  • 13
  • 85
  • 165
0

In C you will get away with these kinds of things. Sometime later other parts of the programs may come in and overwrite the area you are not supposed to use. So it is better not to test these things.

fastcodejava
  • 39,895
  • 28
  • 133
  • 186