Do I "have to" free() static dynamically allocated pointers?

Question

I have a function with a for loop and inside the loop (and depending on the input) certain variables are initialized once (the first time) using malloc().

These variables are declared like this:

static double *vector;

and then I allocate the memory using

malloc(size*sizeof(double));

The Question is:

Do I have to free these variables in the last iteration of the loop inside the called function or not?

UPDATE: maybe I explained myself wrong for some people. The thing is the called function (func_A) allocates memory for certain vectors it uses depending on the input from the main function. Then, this func_A is called several times from a loop in the main. That is why I define the variables as static, so that they are not defined everytime the func_A is called (for a matter of time consumption), because the dimensions will not change throughout the whole run. The variables are static but not global, so I can not free them from the main (right?).

The answer is, "it depends". You have to free the memory *after* you last used it and *before* your program exits... — DevSolar, Sep 08 '16 at 07:59
http://stackoverflow.com/questions/654754/what-really-happens-when-you-dont-free-after-malloc?rq=1 — jamesdlin, Sep 08 '16 at 12:32
**NEVER, NEVER NEVER** call `free(3)` for something you have not made a `malloc(3)`. Look at the manual page. — Luis Colorado, Sep 08 '16 at 12:38
BTW, if you freed the variable in the last iteration of the loop, then what would be the point of making them `static` in the first place? — jamesdlin, Sep 08 '16 at 12:38

score 4 · Accepted Answer · answered Sep 08 '16 at 08:01

4

You should always balance a malloc with a call to free.

In your case, you could call it when you know you no longer need the vector.

If that's not practical then you could always make a call to atexit; passing to it a pointer to a suitable function which will free the memory. See http://www.tutorialspoint.com/c_standard_library/c_function_atexit.htm

Although you can often rely on operating systems to clean up for you on program termination, it's rather crude to rely on that.

answered Sep 08 '16 at 08:01

Bathsheba

231,907
34
361
483

Sir, if I may ask, what sense does it make calling `free()` or equivalent at `atexit()`? Anyways upon program termination, memory will be reclaimed, right? – Sourav Ghosh Sep 08 '16 at 08:13
2

A nice shiny operating system will indeed do that for you, but there's no guarantee of it happening from the C standard perspective. Well-written software always cleans up after itself. – Bathsheba Sep 08 '16 at 08:15
"you could always make a call to `atexit`..." Er, not always. There's a limit to the number of callbacks that can be registered with `atexit`, so using it directly doesn't scale well. (To work around the limit, one could create their own callback registration system and have a single `atexit` callback trigger it.) – jamesdlin Sep 08 '16 at 12:36

Sourav Ghosh · Answer 2 · 2016-09-08T08:08:23.580

Do I have to free these variables in the last iteration of the loop inside the called function or not?

You can, but you don't have to.

You only have to free() the memory allocated by memory allocator functions when you don't need it anymore.

One of the major purpose of memory allocation using malloc() and family is to overcome the limitation regarding scope of local variables (returning address of local variable from a function is illegal), so you never have to free() the memory "inside the called function". You can very well return the pointer (returned by malloc()) to the caller, perform some other operations with that pointer (memory) and then, clean up (free()) the pointer from the caller of the sub-function.

One thing to remember though, you need to pass the exact pointer to free() which was originally returned by malloc() or family.

score 0 · Answer 3 · answered Sep 08 '16 at 08:01

0

Every malloc call needs to have corresponding free call, when the data is not used anymore.

answered Sep 08 '16 at 08:01

CleanCoder265

574
1
5
22

nope, it is good programming style, but it's not something you are forced to do. What is actually needed is to *never* call `free(3)` on something you have not obtained by `malloc(3)` or something you have already `free(3)`d. – Luis Colorado Sep 08 '16 at 12:42

score 0 · Answer 4 · answered Sep 08 '16 at 08:01

0

you need to free the pointer. as a rule of thumb - everything you allocate with malloc/new is on the heap and needs to be free'd/deleted everything else is on the stack and doesn't

p.s. if you only used a grbage collected language such as java/go/python you wouldn't need to know any of this

answered Sep 08 '16 at 08:01

akiva

2,677
3
31
40

Yes but he would then be limited in what he could do. – rassa45 May 16 '18 at 22:52
@ytpillai - what do you mean? – akiva May 17 '18 at 03:24
Java/Go/Python abstract stuff out and require compilers that aren't universally installed. C especially is used pretty much everywhere especially embedded hardware. Better approach is to use something that compiled to C code and then put that code into the compiler of the system you are using, but compiler has to be compatible with whatever standards the system's compiler uses – rassa45 May 17 '18 at 03:59

score 0 · Answer 5 · answered Sep 08 '16 at 08:01

It seems a vector is allocated once and then used during the life time of the prorgam. The vector is stored in the static variable. Before terminating the program it would be a good idea to free the vector, but the termination will also do that for you.

It sounds like the function is not prepared to work with different (in particular: larger) vector sizes during the program's life time.

Do I "have to" free() static dynamically allocated pointers?

5 Answers5