It fails mysteriously if the P is NOT declared static. It works for char data type, but not int or float.
(I was just browsing the GRBL software package where they have the same construction, and it works, presumably. Some time ago I did above and it failed, as I describe. A weak theory is that GRBL presumes a different toolchain to compile... but it still is the same compiler, right?)
Damn. It just goes to show, when writing new and shorter code in the post, instead of doing a cut-n-paste from the real code, one introduces new errors. And there is one more error in my initial post. I was just gettng very very frustrated. Sorry. If you look at the real code (link in above post), you'll see that I do know the difference.
Still the problem is there.
When I write
static int P ;
F ( &P ) ;
:
void function F ( int *P) { *P = 42 ; }
it works fine
BUT when I use
/*dynamic*/ int P ;
F ( &P ) ;
:
void function F ( int *P) { *P = 42 ; }
Can you create a working example that demonstrates the problem? A piece of code with a setup() and a loop() that compiles and prints out the incorrect value? It's unclear which part of the thread you linked to has the problem, and there's no way the snippets you posted here are correct with "void function F" and the random colon.
I really love the "Send us the code, before and after" "explain what you expect".
I do the same. Hey, I even demand the same. (Years ago I was head of support/QA in a company, the official bug report forms I designed had fields for this, with great success) I thought I was above such details this time. Wrong!
There is this great saying, that I use with friends/colleagues, when we hit an "impossible" problem/bug/behaviour in the systems we work with:
"Explain it to the teddy bear"
Usually, when explaining a problem in excruiating detail to the teddy bear (or a colleague ) you suddenly see the problem from a new angle or discover a presumption you made that was never made explicitly clear.
And thus the error is discovereed, the problem solved. Humbly I realized my hidden assumption in this case, too.
So - the example in this thread will work.
My code (see the link) left the calling function (loop) and in again and the called function assumed(!) that the parameter it had gotten was unchanged by the caller. Which it wasn't as it is un-static.
I conclude it is very bad coding style for a function to assume that it can use the by reference parameters as (static) storage, between invokations of being called. Too aggressive in saving precious memory bytes. My excuse is that the function was always inline with global variable. As the linked thread says - I converted it to library, and this is where all probelms began. Before the variables were global but you cant do that with a library. I'll fix the code, and "waste" 3 bytes.
Thank you for reading. Now move along, there is nothing more to see here.