Local variable problems:

[bhattaroshan]

Hi everyone,

Does the variables declared in some function totally destroyed when we come out of the function. Or, is it that the memory address allocated by the variable can be replaced by other programs/functions at any time?

 

[zorro]

Does the variables declared in some function totally destroyed when we come out of the function.?

Yes. Unless the variable is declared as static, its value is lost. Its memory address can further be used by another function, and you don't have any guarantee that the next time the function is called the same memory location is assignet to that variable.
If you want that the variable preserve its value between calls, declare it as static inside the function.
Regards

Z

 

[BradtheRad]

I program in BASIC. The docs say that a variable allocated within a function exists only within the function. When the function ends the variable is dismissed. The memory is supposedly released, and can be used to store other variables.

I don't know whether a block of memory ends up resembling swiss cheese after this is done a number of times. Functions could conceivably be called in a manner that forces the program to allocate ever more blocks of memory to store variables.

 

[bhattaroshan]

OK.. i came to know that the data written in RAM is not necessary to be erased after coming out from the function. But, it can be erased whenever necessary. But, again i have one doubt how can it be found out that particular memory in RAM is not in use, and so can be replaced by some other variables whenever necessary?

 

[FvM]

The most popuar method to assign memory space for local variables is to place them on the stack. This will assure their consistency during "lifetime" and automatical memory space release afterwards. The method is also dealing well with reentrant functions.

Compilers for microcontrollers with restricted stack space (e.g. PIC16/18, 8051) need to manage local variable space explicitely and keeping track of function call levels. Reentrancy is generally causing problems for these compilers.