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()?
myary is local to function1(). Sorry for that.
Hi Andrew,
thank you for this clarification - I never ran across such a compiler.
Martin
Separate "destroy" from "release".
When memory gets released, the contents in the memory may not be destroyed. It might, but that is outside the specifications of the language.
When an auto variable goes out of scope, you just have no right to assume anything about the contents of that memory anymore.
When a memory block gets released with free(), you might still be able to read the same data from the pointer - but doing so is wrong because the documentation for free() doesn't promise anything about the pointer or that block of memory after the call.
Your code doesn't show where that myary buffer is.
And it has two assigns to the pointer but never seems to make use of the memory (myary) that the pointer points to.
'free()' does not do that (unless you have some special version of it - in which case its documentation would tell you).
By "destroyed" i meant the data is over-written.
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?
"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.
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...
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.
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 - 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.
...may be even an badly written ISR)
May even be well written ISR!
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)
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?
View all questions in Keil forum