4 ms·

Well, Though the above code is not freeing up the memory allocated to ‘ptr’ but still this would not cause a memory leak as after the processing is done the pro

Well, Though the above code is not freeing up the memory allocated to ‘ptr’ but still this would not cause a memory leak as after the processing is done the program exits. Well this is always true, so I guess that means there's no such thing as memory leaks in C. Checkmate garbage collectors.

omra 14y ago
Generally modern operating systems free any memory left that the program is not using, but is still accessible. However, if you overwrite an old pointer, there is no way that the operating system could catch that. To illustrate the difference, I wrote two quick programs. This one has memory that the OS can recover: #include <stdlib.h> int main(void) { char *a = malloc(10); return 0; } This one has memory that the OS cannot recover: #include <stdlib.h> int main(void) { char *a = malloc(10); a = malloc(10); return 0; }
- mikeash 14y ago
  So if you run your second example a billion times or so, your OS will run out of RAM? No, that's not how it works....
- Jare 14y ago
  To get rid of the hard memory leak in the second example, just call free(a) twice before returning. They don't call it pointer magic for nothing! /sarcasm
- humbledrone 14y ago
  The OS always recovers all of the memory from a process that has terminated (barring horrible kernel bugs), and it doesn't need to look through the process image for pointers that need to be freed. When a process allocates memory, the kernel doesn't give it a physical memory address. It gives it a virtual address, which, when accessed, will be mapped to some physical address. The kernel has to keep track of which virtual addresses map to which physical addresses for each process, and it stores these mappings in a data structure called a "page table". At all times, the kernel knows what memory segments are in use by a given process. So, when a process exits, the kernel can just look at its page table to see what memory had been allocated to it. Provided that no other processes shared the same memory, it can free it.
pfedor 14y ago
The code in question 4 is not a memory leak by any reasonable definition of memory leak. Allocating a fixed amount of memory and using it until the program terminates, without ever bothering to free it, is a perfectly valid programming practice. Why should it trouble anyone more than say a statically allocated global array? In fact, it's a wiser thing to do than religiously freeing everything at exit. An actual memory leak is when the amount of memory program allocates grows with runtime while the amount of data the program is processing remains the same.

omra 14y ago

Generally modern operating systems free any memory left that the program is not using, but is still accessible. However, if you overwrite an old pointer, there is no way that the operating system could catch that. To illustrate the difference, I wrote two quick programs. This one has memory that the OS can recover: #include <stdlib.h> int main(void) { char *a = malloc(10); return 0; } This one has memory that the OS cannot recover: #include <stdlib.h> int main(void) { char *a = malloc(10); a = malloc(10); return 0; }

mikeash 14y ago
So if you run your second example a billion times or so, your OS will run out of RAM? No, that's not how it works....
Jare 14y ago
To get rid of the hard memory leak in the second example, just call free(a) twice before returning. They don't call it pointer magic for nothing! /sarcasm
humbledrone 14y ago
The OS always recovers all of the memory from a process that has terminated (barring horrible kernel bugs), and it doesn't need to look through the process image for pointers that need to be freed. When a process allocates memory, the kernel doesn't give it a physical memory address. It gives it a virtual address, which, when accessed, will be mapped to some physical address. The kernel has to keep track of which virtual addresses map to which physical addresses for each process, and it stores these mappings in a data structure called a "page table". At all times, the kernel knows what memory segments are in use by a given process. So, when a process exits, the kernel can just look at its page table to see what memory had been allocated to it. Provided that no other processes shared the same memory, it can free it.

pfedor 14y ago

The code in question 4 is not a memory leak by any reasonable definition of memory leak. Allocating a fixed amount of memory and using it until the program terminates, without ever bothering to free it, is a perfectly valid programming practice. Why should it trouble anyone more than say a statically allocated global array? In fact, it's a wiser thing to do than religiously freeing everything at exit. An actual memory leak is when the amount of memory program allocates grows with runtime while the amount of data the program is processing remains the same.