Trying to understand how to return an array from a function. Can you help me understand what I should be doing to get a reference to the breakfast array in the code below?
void setup() {
Serial.begin(9600);
char food[] = "Pizza";
char* food_ptr = food;
Serial.print("\nfood_ptr before the call: "); Serial.println(food_ptr); // prints "Pizza"
food_ptr = foo();
Serial.print("food_ptr after the call: "); Serial.println(food_ptr); // prints nothing
}
char* foo(){
char breakfast[] = "bagel";
return breakfast;
}
You can't return a a pointer to a variable that's local to the function. Define the array in the calling function and pass that into the called function (along with the array's size).
Oh yes you can - but it is a very bad thing to do!!
The pointer will continue to point at the memory location where the local variable once was - but that memory will no longer be occupied by that variable!
You will create some very bewildering and hard-to-debug bugs this way!
Therefore, you really do not want to do this!
Instead, as @gfvalvo said, pass-in a pointer to a buffer for your function to use.
Well a pedant would take a minute to point out that you can return a pointer to a variable that's local to the function, if it is declared static.
And another minute to carefully make clear that he is not recommending that in case someone somehow thinks he is.
It might could be just what you want to do. I'll ask the AI I have trained on 50000 lines of my own code to see if I ever happened to do that, and see if it was for any good reason.
Thank you all very much for your responses. You've given me lots to think about and to look up.
To alto777's point, I saw in a digitalOceans tutorial that you could return a pointer that points to a local static array, like this:
and that works (in this case anyway) but I think you are saying that is a bad idea. Can you explain why it's bad? Is it because I can't use that memory somewhere else now? Thank you again!
EDIT: I changed static function to static array (thanks to awneil for pointing that out).
It is common practice to send the array pointer and the size of the array as function arguments...
That way you can prevent writing ouside array biundaries...
Like with snprintf(char* ptr, int size)...
It turns out that this is a relatively difficult thing to do in C.
The best solution is usually to define the array outside of the function, and pass the array (and its length) to the function as arguments:
char *food = "Pizza";
Serial.print("\nfood before the call: "); Serial.println(food);
foo(food, sizeof(food));
Serial.print("food after the call: "); Serial.println(food);
}
char *foo(char* s, size_t len){
strncpy(s, "bagel", len);
return s;
}
Recursive code has the potential to grow the hell out of the stack.
If the function always finishes before too many recursions it won't crash your sketch. How many too many is depends on space left.
Strange though, I write functions that get called a lot, finish a short step and return to be called again and again to achieve results I might use recursion to achieve in a larger memory computer.
To me it was clearly reinforcing what you said in an humorous way something like « you are authorized to shoot yourself in the foot »… hopefully no one would do it…
I've actually seen this in one of the real-time clock libraries, for returning text for the day of the week if I recall correctly.
This can lead to hard to debug errors. If the function is called multiple times, and changes the data in the array each time, then you cannot save the pointer from a previous call and expect to have the old data, since every call to the function returns a pointer to the same array, which will contain only the data from the last call to the function.