C function memory allocation

Question

In C, at what time is a function allocated and where in memory does it go?

Is the memory for a function allocated when the program is compiled first or is it allocat

Answer 1

Inline Function...

Great Explaination...

I would like to provide details about the memory allocation for inline function which is not covered. Inline function can be thought of a macro, where the call to the function is replaced by the code and also does the argument evaluation. Giving a key word inline before a function need not make it an inline function, it merely suggests compiler that this is a candidate for inline. The compiler ultimately chooses whether this could be an inline function. Hence the memory allocation would be similar to a function.

Answer 2

Yours is a good question, but be prepared for some extra complexity, because some of this stuff touches the bare transistor in the CPU running the code...

I choose to fail miserably trying to condense it into 4 types.

• global storage
• code storage
• local storage
• dynamic storage

Code storage should be pretty straight-forward, so I'll just complicate it a bit: a cluster of thoughts translated into a procedural language snippet, henceforth called "function", got translated into a sequence of machine instructions.

Those need to be fetched and executed by the processor, so it must lay in ROM or RAM... defining a code storage area. Even if the function is called multiple times or even recursively, there is only one instance of its code.

(let's not get into in-linning)

---

Global data storage is RAM where all not-in-a-function declared variables get to live (only one instance per declaration), plus the ones declared as static (in or out of a function). These get referenced by absolute (or quasi) addresses.

Constants may or may not get their own ROM-storage area... its compiler/optimization specific.

---

Local storage of a function is a bag for argument/return passing and local variables (declared in it, hence only visible by it), and every call to the function needs a separate bag so that each call gets it's individual context.

Usually (there are memorable exceptions) we use a Call-Stack mechanism to pile up the several local storage areas that each function call generates. It's increasingly uncertain, but you'll find that this is a stack-frame that grows in DEcrementing memory addresses.

So Local storage is where the compiler function-calling code (auto-done for you) places the arguments for the functions, the return placeholder for the called function, the return address of the calling function, and all non-static (and optimized to internal register-usage) variables. One per each calling. The function code where these local variables and arguments are referenced, will ...err.. reference the latter through the Stack-Pointer plus an offset, a CPU register that points to the current Stack-frame end address (how could the function code know the memory addresses otherwise?).

Calling a function involves setting up it's Local storage, eventually copying arguments into it (pushing into the stack) and initializing some of the locals, then jump to the function code. Returning is copying the called-function return value into caller-function Local storage, destroy the called-F local storage, placing the Stack Pointer at the end of the previously piled Local storage bag, and jumping to the saved caller next-instruction address (poping things out). All done.

Looking at a memory snapshot of a single C process, you could make out a Stack with several bottomed-piled Local storage areas, that will block grow and shrink following the function call/return pattern that a specific program executes.

---

Dynamic memory is commonly managed by malloc and free: keepers of a growing-addresses stack of blocks of memory that you access through pointers. This forms a wrongly named Heap area (because in time you will most likely get a swiss cheesse, not a heap).

These memory chunks can be used for any purpose, and the challenge is to make sure one does not forget to free them, otherwise in time you will "leak" into the call stack (easy to see how destructive that will be).

It requires a bit of extra discipline to use dynamic memory managed by malloc/free, but is considerably useful to avoid huge local or wasted global storage (in situations where a function needs to handle a bunch of data and can get called a few times, or a big chunk of data that very rarely needs to be in memory).

Dyn-memory area is usually sandwiched between global and the Stack... Some embedded compilers will let you specify the size of the two.

Malloc and free are not the only ways to manage dynamic memory, and I'm currently using a home-grown reverse-reference allocator which does not require a free(). Undisciplined code and no leakages.... yaayy!

Answer 3

The memory for C functions is always allocated from the code segment at the time the functions are loaded into memory. If a function belongs to a dynamically linked library, the program may load and unload it at arbitrary times.