Ytukyg

This question is aimed at improving my understanding of

what I can and cannot do with pointers when allocating and freeing:

The bellow code is not meant to run, but just set up a situation for the questions bellow.

char *var1  = calloc(8,sizeof(char));

char **var2 = calloc(3,sizeof(char*));



var1 = "01234567";



var1[2] = '';

var1[5] = '';



//var1 = [0][1][][3][4][][6][7]



var2[0] = var1[0];

var2[1] = var1[3];

var2[2] = var1[6];



free(var1);

free(var2);

given the following snippet

1: is it ok to write to a location after the if you know the size you allocated.

2: Can I do what I did with var2 , if it points to a block that another pointer is pointing at?

3: are the calls to free ok? or will free die due to the located throughout var1.

I printed out all the variables after free, and only the ones up to the first null got freed (changed to null or other weird and normal looking characters). Is that ok?

4: Any other stuff you wish to point out that is completely wrong and should be avoided.

Thank you very much.

Ok, let's just just recap what you have done here:

char *var1  = calloc(8,sizeof(char));

char **var2 = calloc(3,sizeof(char*));

So var1 is (a pointer to) a block of 8 chars, all set to zero .
And var2 is (a pointer to) a block of 3 pointers, all set to NULL.

So now it's the program's memory, it can do whatever it wants with it.

To answer your questions specifically ~

It's quite normal to write characters around inside your char block. It's a common programming pattern to parse string buffers by writing a after a section of text to use everyday C string operations on it, but then point to the next character after the added and continue parsing.

var2 is simply a bunch of char-pointers, it can point to whatever char is necessary, it doesn't necessarily have to be at the beginning of the string.

The calls to free() are somewhat OK (except for the bug - see below). It's normal for the content of free()d blocks to be overwritten when they are returned to the stack, so they often seem to have "rubbish" characters in them if printed out afterwards.

There is some issues with the assignment of var1 ~

var1 = "01234567";

Here you are saying "var1 now points to this constant string". Your compiler may have generated a warning about about this. Firstly the code assigns a const char* to a char* (hard-coded strings are const, but C compilers will only warn about this [EDIT: this is true for C++, not C, see comment from n.m.]). And secondly, the code lost all references to the block of memory that var1 used to point to. You can now never free() this memory - it has leaked. However, at the end of the program, the free() is trying to operate on a pointer-to a block of memory (the "01234567") which was not allocated on the heap. This is BAD. Since you're exiting immediately, there's no ill-effects, but if this was in the middle of execution, the next allocation (or next 1000th!) could crash weirdly. These sorts of problems are hard to debug.

Probably what you should have done here (I'm guessing your intention though) is used a string copy:

strncpy(var1, "01234567", 8);

With that operation instead of the assignment, everything is OK. This is because the digits are stored in the memory allocated on line1.

Question 4 - what's wrong

You 'calloc' some memory and store a pointer to it in var1. Then later you execute var1 = "01234567" which stores a pointer to a literal string in var1, thus losing the calloc'd memory. I imagine you thought you were copying a string. Use strcpy or similar.

Then you write zero values into what var1 points to. Since that's a literal string, it may fail if the literal is in read-only memory. The result is undefined.

free(var1) is not going to go well with a pointer to a literal. Your code may fail or you may get heap corruption.

Pointers don't work this way.

If someone wrote

int a = 6*9;

a = 42;

you would wonder why they ever bothered to initialise a to 6*9 in the first place — and you would be right. There's no reason to. The value returned by * is simply forgotten without being used. It could be never calculated in the first place and no one would know the difference. This is exactly equivalent to

int a = 42;

Now when pointers are involved, there's some kind of evil neural pathway in our brain that tries to tell us that a sequence of statements that is exactly like the one shown above is somehow working differently. Don't trust your brain. It isn't.

char *var1  = calloc(8,sizeof(char));

var1 = "01234567";

You would wonder why they ever bothered to initialise var1 to calloc(8,sizeof(char)); in the first place — and you would be right. There's no reason to. The value returned by calloc is simply forgotten without being used. It could be never calculated in the first place and no one would know the difference. This is exactly equivalent to

char* var1 = "01234567";

... which is a problem, because you cannot modify string literals.

What you probably want is

char *var1  = calloc(8, 1);     // note sizeof(char)==1, always

strncpy (var1, "01234567", 8);  // note not strcpy — you would need 9 bytes for it

or some variation of that.

var1 = "01234567"; is not correct because you assign a value of pointer to const char to a pointer to mutable char and causes a memory leak because the value of pointer to a calloc allocated buffer of 8 char stored in variable var1 is lost. It seems like you actually intended to initialize allocated array with the value of the string literal instead (though that would require allocation of an array of 9 items). Assignment var1[2] = ''; causes undefined behavior because the location var1 points to is not mutable. var2[0] = var1[0]; is wrong as well because you assign a value of char to pointer to char. Finally free(var1); will try to deallocate a pointer to buffer baking string literal, not something you allocated.