CODEWITHSUNDEEP
c
user208390
user208390

Reputation:

No error even when I'm overriding the limit of allocated memory?

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;
}

Upvotes: 7

Views: 164

Answers (4)

Clifford
Clifford

Reputation: 93524

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.

Upvotes: 1

fastcodejava
fastcodejava

Reputation: 41117

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.

Upvotes: 0

John Knoeller
John Knoeller

Reputation: 34158

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.

Upvotes: 3

Michael Burr
Michael Burr

Reputation: 340306

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).

Upvotes: 6

Related Questions