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
"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.