This forum may not be the best to ask the question, but the answers on the other forums (that i know) were generally with respect to C for desktop pc (where memory management is different from that in embedded) and this forum has knowledgeable embedded people. hence...
I was worried about the following situation:
void function1() { ... //other variables char* ptr = myary; ... ptr = ReadNandFlash("myfile"); ... } char* ReadNandFlash(char* Filename) { FILE* file; char temp_ary[256]; file = fopen(Filename, "r"); if(file == NULL) { return NULL; } while(!feof(file)) { fread(temp_ary, sizeof(char), 256, file); } fclose(file); return ary; }
will the 'temp_ary' be destroyed as only the pointer value is returned back to the function1()?
This should solve the problem:
char* ReadNandFlash(char* Filename) { FILE* file; static char temp_ary[256]; file = fopen(Filename, "r"); ... }
It may solve the problem, but it will keep the 256bytes of space always reserved. It want that 'temp_ary' be destroyed once the data is copied. one way is to use 'calloc/malloc' and 'free'.
other way is to pass the 'myary' to 'ReadNandFlash()'. But i was still curious about the lifetime of data in the memory.
Google for automatic variables and you will find the answer to your question.
Data on the stack will live until it is reused, which is likely to happen on the next function call. Regarding this, there is no difference between a PC or an embedded environment. Interrupts and other tasks use their own stack. Nevertheless, this is a risky situation where later additions to the code may destroy the data, because the programmer is not aware where the data is stored. Making the array static, as Franc suggested, will of course work and decrease stack usage, which normally is kept short on embedded systems. For clarity, it seems to be advisable to turn things round: Introduce the array earlier in the call chain (static or on stack), and pass pointer to it and size to "ReadNandFlash".
Martin
Returning an address to an auto variable is not something that is different between embedded and PC - it is something that isn't part of the language standard. In short: it is invalid code that in some situations might work. Do you want invalid code that might in some situations happen to work?
other way is to pass the 'myary' to 'ReadNandFlash()' This will work.
What you are trying to do may/may-not destroy the array data in the memory. But there is no guarantee of it working always. There may be other piece of code which may change the data (other piece of code can be threads, or may be even an badly written ISR)
...may be even an badly written ISR)
May even be well written ISR!
Yes - for processors that has a common stack for ISR and main code (this includes a lot of processor architectures), the ISR is guaranteed to overwrite auto variables from returned functions.
And this thread is "Non-Specific (Generic)" so we can't assume any ARM chips that switches stack.
For clarity, it seems to be advisable to turn things round: Introduce the array earlier in the call chain (static or on stack), and pass pointer to it and size to "ReadNandFlash".
Totally this
Yes - when using the stack for temporary storage, then that storage should obviously be in a part of the stack that the active call tree owns - which is why it is safe to have a buffer on the stack and send a pointer to that buffer to a function that gets called.
But it is not safe to call a function that returns a pointer to a buffer in that functions stack space.
The location of the buffer must be selected so that the lifetime of the buffer isn't shorter than the need for the buffer.
char buf[100]; snprintf(buf,sizeof(buf),"%u",value);
The above have a local buffer and sends a pointer to that buffer to another function - i.e. the safe route to play with stack-allocated buffers.
Not necessarily!
Remember that this is marked as a Non-Specific (Generic) topic. Not all compilers - notably, not all Keil compilers - use the stack for automatic variables...
"it will keep the 256bytes of space always reserved. It want that 'temp_ary' be destroyed once the data is copied"
What, exactly, do you mean by "destroyed"?
"one way is to use 'calloc/malloc' and 'free'"
No, that would not physically "destroy" the data - it would still be there. And you'd still have to keep memory reserved for the Heap.
void function1() { ... //other variables char* ptr = myary; ... ptr = ReadNandFlash("myfile"); ... }
What if we make the function1 a critical section, so that nothing can "interrupt" the function1. I guess it would always work safely?
By "destroyed" i meant the data is over-written.
'free()' does not do that (unless you have some special version of it - in which case its documentation would tell you).