0

if I allocate memory using malloc(), do I have to call free() afterwards even if the program exits?

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

int main()
{
    int *a = malloc(sizeof(int));
    *a = 10;
    printf("%d", *a);
    free(a);
    return 0;
}

What happens to the memory after the program exits if I don't call free()?

user9513592
  • 23
  • 5
  • Another dup: [When you exit a C application, is the malloc-ed memory automatically freed?](https://stackoverflow.com/questions/2213627/when-you-exit-a-c-application-is-the-malloc-ed-memory-automatically-freed) – Weather Vane May 19 '18 at 20:15

2 Answers2

1

All memory will be freed when the program exits. The point of using free is so you do not cause memory leaks that make your program eat up more memory than it needs while it runs.

Christian Gibbons
  • 4,272
  • 1
  • 16
  • 29
  • That depends on the OS. – Weather Vane May 19 '18 at 20:15
  • 1
    @WeatherVane What OS doesn't automatically release resources? Even a program on DOS years ago would release memory on program termination (simply by the virtue that nothing was managing the memory when the program stopped). – Imobilis May 19 '18 at 20:38
  • @Malina did you read the link in my comment above? The question is tagged C, not OS. In C, `malloc` and `free` should be matched, not a reliance on "hey, the OS will do it." – Weather Vane May 19 '18 at 22:04
  • @Malina the accepted answer to that question, saying "It depends on the operating system" has 90 upvotes. – Weather Vane May 19 '18 at 22:12
  • @WeatherVane I am not saying malloc/free shouldn't be matched. Of course it should, otherwise why would standard bother to create `free()`. Also I agree relying on OS is bad practice. Up-voting used to mostly mean that people found it useful not that it is true. In this case it is true, but it doesn't say why it depends on OS, when or on which OS it depends. It says that the majorify of OS will free the resources automatically on the other hand. I doubt that OP programs on some obscure embedded non-computer computer. – Imobilis May 19 '18 at 22:24
  • 1
    @Malina don't put down embedded systems as "obscure". It does not mention an OS because that OS may not yet have been written, and there is no requirement that an OS should clean up after lazy C programmers have gone to lunch. My comment remains: it is OS specific. – Weather Vane May 19 '18 at 23:15
  • @WeatherVane I never meant it is wrong, Weather you are a fantastic guy I like you. Don't take it on that way :) – Imobilis May 19 '18 at 23:24
  • If the target OS manages memory in a non-trival fashion, and performs process resource cleanup in an effective manner, not relying on the OS is bad practice. Avoiding actual memory leaks from lost allocations by freeing memory is one thing, and I'm sure nobody would disagree with that, but deliberately choosing to leave one-off app-lifetime allocations to the OS for deallocation is often preferable to often-complex, counter-productive or imposs.. very, very difficult user-space cleanup code. – Martin James May 20 '18 at 04:05
0

You don't have to, but you should to avoid memory leaks.

Michael Loda
  • 51
  • 10
  • 1
    Well, to be fair, the OP's example would not be a memory leak. If the free() is omitted, the app still has a reference to the malloced space. It's not a leak unless you overwrite the pointer. – Martin James May 20 '18 at 03:07