Why is the output of this code not 012?

Question

https://code.sololearn.com/c9X79p441Uw2/?ref=app

Answer 1

jay after the increment, p and q definitely point to different elements.
https://code.sololearn.com/c1ehusGBt0E4/?ref=app

Answer 2

Idk about C and pointers, but my logic say:
q is a pointer of p, when you free p, q falls out of value.
I tried it by removing the line "free" and the result is 012

Answer 3

Thanks InvBoy . I thought that only the fourth element would get freed and that if the entire block of 4 integers got freed, I would have got a segmentation fault/error. So no error but no output confuses me.

Answer 4

So I guess it is the same number of bytes that were originally malloced that get freed, right? So free(p) will try to free 4 * sizeof(int) bytes but fail, giving rise to undefined behavior? I was expecting a segmentation fault/error rather than a seemingly clean 'No output'.

Answer 5

Your program would work if it had one more level of indirection (an array of int * instead of int). Otherwise, you've thought about it correctly.
Your 'p' pointer points to an allocated block of memory for an array of 4 integers. 'q' then points to 'p' which holds the address of the first element in the array.
Then you increase the 'p' pointer offset by 3, so 'p' now points to the the 4th element in the array.
Your call to free(p) attempts to free the 4th element (which is an integer) and you'll end up with memory corruption, since no memory was allocated for the integer itself. :-)
It's akin to writing something like this:
int num[4] = { 0, 1, 2, 3 };
int *p = num + 3;
free(p);
So the problem isn't that free(p) frees the entire array (it doesn't) as it is offset by 3. The problem is that you're attempting to free an integer rather than a pointer which holds memory for an integer.
Here's a quick demo:
https://code.sololearn.com/c194pe7TV4hq/#c

Answer 6

Sonic
malloc() allocates memory dynamically and the returned address is stored in pointer p, that is storing to pointer q.
But at the time of second loop for printing stored element pointer q goes to at that line of declaration of int *q=p ; but p is already free so there is no output generated.

Answer 7

When you do p+=3; free(p); you have an undefined behavior and I guess in this case, your program just terminates

Answer 8

I see now hahaha silly me, didn't take into account him going past the reserved memory area haha

Answer 9

Same. But clearly here be dragons
(for those unfamiliar with the saying: https://en.m.wikipedia.org/wiki/Here_be_dragons )

Answer 10

InvBoy is correct.
P and Q point to the same location.
https://code.sololearn.com/cog35COSGDhq/?ref=app

Answer 11

When you have an undefined behavior, the compiler can do pretty much whatever it wants.

Answer 12

So to resize realloc should be called?

Answer 13

Ran the program on codingground and you can see that you get a core dump.
Meaning the free on p + 3 crashes your program

Answer 14

Hello sonic, it's the free you're free in your storage before you print it

Answer 15

The free of p+3 is wrong because you are trying to free memory which has not been initialized. It leads to undefined behavior. You will get a runtime error.

Answer 16

p+=3; I’m not sure, but
free(p); needs a pointer
free(*p);

Answer 17

Here are my thoughts. First this appears to be a runtime error, as there are no error messages. It must be the operating system booting the program.
Second, I wanted to know if using free(q) would work since p was used in allocating the memory. This seems to work, as does free(p-3), which is the original value of p.
It's interesting the output when you try to print the array after the free. The first and third values are very large integers that start with the same digit. The second and fourth are always zero. I dont have any explanation for this.
https://code.sololearn.com/cd34TnEfgR7F/?ref=app

Answer 18

You must delete (free(p);)
And the problem will be fixed