Passing any arrays by value or pointer does not work very well.
I can try integrating an array into a structure, but that is not how I would do it.
if I have: frame( unsigned char &mbrtubuf, int &uslen) and the receiving side is :
frame ( unsigned char *somepointer, and int *uslen) neither of the variables are passed
correctly to the function. Prototype is in a header file. Does not work and when it does work
its becomes unstable. Terrible compiler. It should work and I should even have to think
about it. I spend more time on the Compiler then I do on the actual program.
The only way I can get the array into a fucntion is by declaring it external in the function.
Any ideas
Phil
No! As already pointed out, you do not need that!
See: c-faq.com/.../extern.html
Therefore, this is not what "fixed" your problem.
In general, when you don't know what "fixed" a problem, you should assume that it is not fixed; you have probably just (temporarily) masked the symptoms - not fixed the cause.
"This might also solve some other issues I had with function pointers but that is another topic all together."
Highly unlikely!
As already noted, there are far more fundamental issues with function pointer in C51. Have you studied those issues yet?
"my biggest problem is learning what tools work"
It sounds much more likely that your biggest problem is that you are trying to build a large project without having first grasped the basics of 'C' programming.
You really need to lay solid foundations before building the upper storeys of the house!
The tools work - but you have to spend time learning how to use them correctly & effectively.
"Is there a file that would show memory locations and how they are linked?"
Yes - it is called the Linker Listing or "map" file.
"Therefore, this is not what "fixed" your problem."
if your assertion is that you don't know what the problem is, you necessarily don't know what "fixed" the problem.
the op's solution (of using "extern") may not be the right fix for his problem, but that doesn't mean the use of "extern" isn't the fix for his problem.
"if your assertion is that you don't know what the problem is, you necessarily don't know what 'fixed' the problem"
No, that wasn't my assertion.
My "therefore" referred to the fact that 'extern' is entirely redundant on a function prototype; that's why it directly followed my citation of c-faq.com/.../extern.html
Since the presence or absence of the 'extern' makes no difference to a function prototype, it follows that adding (or removing) 'extern' to (or from) function prototypes cannot have been the fix to the OP's problem.
I then went on to say:
"In general, when you don't know what "fixed" a problem, you should assume that it is not fixed; you have probably just (temporarily) masked the symptoms - not fixed the cause"
"it follows that adding (or removing) 'extern' to (or from) function prototypes cannot have been the fix to the OP's problem."
just because it cannot fix the problem doesn't mean that it doesn't fix the problem.
Of all the people, you are the one who generalized that sometimes not all things work per specification / logic / etc., in another thread.
just because it isn't supposed to work doesn't by itself mean that it doesn't work. and in this case, the OP's experience trumped your "logic".
No, I never said that.
"just because it cannot fix the problem doesn't mean that it doesn't fix the problem"
Eh??!
If it cannot fix the problem then, by definition, it did not fix the problem!
Most likely, some other change that also happened (intentionally or otherwise) in the process of adding/removing the 'extern' is what caused the change of behaviour.
And, again, the "change of behaviour" may be just a masking of the symptoms - not a fix of the problem.
"just because it cannot fix the problem doesn't mean that it doesn't fix the problem."
That does not compute.
A change can _seem_ to fix a problem. A change can _hide_ a problem.
That something seems to work after a change is not proof that the change fixed the problem.
Think about an uninitialized variable on the stack.
Changing the call sequence can change what value the variable gets. So the behaviour can change - the program may suddenly "work". But as long as the variable doesn't have a "real" initialization, the program is still buggy. And the bug will most probably return again when other changes are made that changes the random noise on the stack when the function gets called.
We shouldn't discuss masking of errors. We should discussing fixing of errors.
Or it could have been pure coincidence.