Thread: Static Vs Dyanmic Allocation

In cases were you have to return a pointer to memory that will not be modified outside its creating function, is it OK to use a static variable instead of calling malloc?

I'm fine with using malloc when I don't know the amount of memory I need before runtime, however, in cases where I do, I feel its wasteful -and not to mention more error prone- to use the heap when a simple static var would work. On the other hand, I don't like calling bzero to clear the static object on each subsequent call. I feel it goes against the purpose of the static variable, which is to hold its state between

calls.What do you guys think?

Originally Posted by Dren

In cases were you have to return a pointer to memory that will not be modified outside its creating function, is it OK to use a static variable instead of calling malloc?

It can be okay, but it is error prone. A common kind of mistake would be when the caller calls the function twice, possibly with the second call hidden inside another function call, not expecting the value to change (as it "will not be modified outside its creating function" after all), but it does! Related to this, such an approach would not be threadsafe.

Originally Posted by Dren

I'm fine with using malloc when I don't know the amount of memory I need before runtime, however, in cases where I do, I feel its wasteful -and not to mention more error prone- to use the heap when a simple static var would work. On the other hand, I don't like calling bzero to clear the static object on each subsequent call. I feel it goes against the purpose of the static variable, which is to hold its state between calls.What do you guys think?

Use a fixed size array instead then, one that is passed to the function as a pointer to its first element.