tags:

views:

78

answers:

3

When I declare this function:

void vLFSR_ParseInput(unsigned char * pucDataArray,unsigned char unCount){}

and try to pass it this array

unsigned char g_ucUSCI_A0_RXBufferIndex = 0x00;   
unsigned char g_ucaUSCI_A0_RXBuffer[RXBUFFERSIZE];

with this function call

vLFSR_ParseInput(&g_ucaUSCI_A0_RXBuffer,g_ucUSCI_A0_RXBufferIndex);

my compiler gives me this error

argument of type "unsigned char (*)[255]" is incompatible with parameter of type "unsigned char *"

What am I doing wrong? If it helps, I am programming using TI Code Composer Studio, and my platform is the MSP430x2xx family.

edit: fixed formatting

+2  A: 

You should use:

vLFSR_ParseInput(g_ucaUSCI_A0_RXBuffer,g_ucUSCI_A0_RXBufferIndex); 
                 ^ no unary &

An array is implicitly convertable to a pointer to its initial element, so when you use g_ucaUSCI_A0_RXBuffer in most contexts, it decays to a pointer to its initial element, as if you had written &g_ucaUSCI_A0_RXBuffer[0]. The type of that is unsigned char*.

When you apply the unary-& to an array, it gives you the address of the array. This has the same pointer value, but its type is unsigned char (*)[RXBUFFERSIZE].

James McNellis
Just to clarify, the issue is that you're passing the address of the pointer. The `[]` in an array access are a dereference. The array name by itself is the equivalent of a pointer to the value.
Bryan
@Bryan: No, the OP is _not_ passing the address of a pointer; he is passing the address _of the array_.
James McNellis
@James McNellis: Yes he is. `char S[3];` ` // <-- what is my type`
nategoose
James McNellis
@James Thank you very much!
some.hacker
@James McNellis: `char S[3];` `char **pp = ` Compile that with the highest compiler warning level you can find. Array names evaluate to pointer literals when most operations are done to them.
nategoose
James McNellis
@James McNellis: Sorry. You were right. It's not often that a base C language issue trips me up like this. As far as the OP's problem goes the fix is the same, but now I'm left wondering about uses and reasons for this evaluating that way. +1 +1
nategoose
@nategoose: No problem. The relationship between arrays and pointers is easily one of the most confusing parts of the C language.
James McNellis
A: 

In an array, e.g. x[10], the "x" is treated as a pointer to a block of memory large enough to hold 10 elements (and the [] is a syntax for dereferencing this pointer to access individual elements within this block).

If you add an & in front of this, you are taking the address of the pointer, not the address of the array memory. That is, you have created a pointer-to-a-pointer, which is a (char **) rather than a (char *).

Just remove the & and it'll be fine.

Jason Williams
An array is not a pointer. An array is an array.
James McNellis
@James - to clarify what I mean, an array is a block of memory. x is a pointer to the array. The syntax "x[0]" or "*x" dereferences this pointer to access the first element of the array.
Jason Williams
James McNellis
@James: I'm not trying to redefine or even quote the C standard here. The OP can read that if he wants a technically perfect description. However, when someone is struggling with a novice question about pointers, IMHO they may find it easier if we describe things in a simpler way. In this context, something that is implicitly converted to a pointer is indistinguishable from a pointer, and can be thought of and treated as a pointer with no ill effects. Indeed, used in that way, the OP may even understand the answer. I'll let others quote chapter and verse to fill in what I skimmed over.
Jason Williams
John Bode
Which "problems later on"? After 18 years of working with C-based languages I have yet to encounter any. The answer "x is an array type" is more "correct" but is the precise reason the OP was confused in the first place - IMHO the critical thing the OP needed to understand is that if you *use* x (outside of sizeof etc) it is *treated* as a pointer, not as "the array". I don't care if my answer is "the correct answer", I just want to help a guy understand why his code didn't work as he expected. The other answers can (and do) explain the technical nitty gritty should he wish to dig deeper.
Jason Williams
How about `void f(int**); int a[1]; f(
Georg Fritzsche
@Georg: a and a[1] are not referring to the same thing. a is "the array" (it is the address of the block of memory holding the array contents, which happens to be where the first element is stored), while a[1] is "the second element of the array".
Jason Williams
I never said they were referring to the same thing. Your answer says *"you have created a pointer-to-a-pointer"* which the OP doesn't as the error message already tells us - he created a *pointer-to-array*.
Georg Fritzsche
A: 
vLFSR_ParseInput(g_ucaUSCI_A0_RXBuffer,g_ucUSCI_A0_RXBufferIndex);

Arrays evaluate to pointer literals (meaning, roughly, a number whose type is a pointer to the type that the array is made of).

You were taking the address of a pointer literal ( similar to int *x = & 4; ) and trying to pass that in to a function that expected a pointer. You were trying to give it a pointer to a pointer.

And you were passing by reference, not by value. Passing arrays by value in C takes a lot of work, and is rarely done.

nategoose
Same here, he is not passing a pointer-to-pointer but a pointer-to-array.
Georg Fritzsche