Dynamically Allocated Static Variable

if i have a function with a static local variable, that's dynamically allocated once:
int funct(void)
{
static char* buffer = NULL;

if (!buffer)
buffer = malloc(SIZESLOW);
}

If there's no explicit free call, and if the process is killed; does this constitute as a leak? When the process is killed, is the heap essentially freed? I guess I'm after an in depth explanation on what happens on a windows platform (i imagine unix would be in the same boat)

It's platform-dependent, not guaranteed by the language. I believe ozo's answer is correct for most, if not all, current operating systems, but I believe it is not true for some old versions of Windows.

From an efficiency perspective, it's fine. If you have a good reason for allocating the memory dynamically (e.g., SIZESLOW is not known until run time, as ozo said), it's fine. If you could just use a statically allocated array, that would be simpler and save you from worrying about whether the memory leaks, so I'd consider that preferable, but not by much.

> not guaranteed by the language
This is true. The language specs say nothing about what happens after the program exits.

0

spifflesAuthor Commented: 2008-06-09

Yeah I'm doing some code reviews and was worried about a potential leak since there's no explicit free call. By the sounds of it, it's probably safe for the platform it's deployed on.

Closer inspection reveals SIZESLOW has elements which could be updated after a product restart. There's also a comment about dynamic allocation being used to avoid stack overflow. Anyways thanks ozo, efn for the feedback.

This is not specified by the language. However, I have never heard of any compiler that does not release the memory when the program terminates.

Note that the behaviour is implementation specific but depends on the compiler run-time routines (in cooperation with the operating system in some implementations).

However, one important thing to note is that some run-time libraries may report this as a problem. For example, Microsoft compilers have for some time been reporting this sort of allocation as a "memory leak" in debug builds, although a one-off allocation is not a "leak" more a "splash". But if you rely on this reporting to find real memory leaks you may want to free the memory when the program terminates. In C you can do this by registering a function pointer with atexit().

0

spifflesAuthor Commented: 2008-06-12

Yes atexit would be a good alternative, but since there's no precedence in the existing code based, I probably won't use it.