Much the same syntax as when passing anything, in this case a pointer is the norm:
int myFunction(char* anArrayOfChars) // a pointer to the array
// function code ...
// calling codechar anArray;
// fill the arrayintvalue = myFunction(anArray) // name of the array is a pointer to its content
will modifying the array content within the function make the edit permanent i.e. the modification will remain after the function ceased to exist. i.e. "myFunction(&anArray)" won`t this edit outside the function. I need the edit to work backwards.
Yes, if the function changes anything in the array then that data will remain when the function returns to the caller. Note: you do not need the addressof operator (&) on an array name. Just code it as I showed in my example.
Try this simple test:
Well, of course that breaks it so you may find that your code crashes. You must not overwrite arrays that are passed to you with more data than it can hold. But this conversation is missing some vital information. Maybe you can explain exactly what problem you are trying to solve.
This will prevent data overflows, and/or segfaults, when accessing myArray inside the function.
Things to note:
* we can get the compiler to tell us how many elements in the array using the sizeof(myArray)/sizeof(myArray) construct. This is calculated at compile time and in release mode, in most cases it will be optimized out, so it does not add to your memory usage, if that's a concern.
* Using the constant arrLen means that if we change the number of elements in myArray, we don't need to go through the code and find all uses of myArray and make sure we're passing in the right number
* If we had used arrLen = sizeof(myArray)/sizeof(int), we need to remember to change the definition of arrLen if we change the type of myArray. Using sizeof(myArray mean that if we change the type of myArray from int to double, for example, we don't need to remember to change the definition of arrLen as well
The leading '_' indicates it's a system level macro, i. e. Windows specific.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Under C any pointer is already a pointer to an array it's built into the language along with pointer arithmetic ... you need to just learn that.
Literally declare any pointer of anything lets do a float
now you can access it as an array
p = 5.0;
p = 10.0;
It will crash because the pointer isn't really to any memory but it makes the point the pointer is already a pointer to an array
There are no exceptions to the rule it doesn't matter if the pointer is to a fundamental type or struct .... so I don't get how you could ever forget that. In the C community the  use is rare because it's two extra characters to type. It also has implication when declaring variables because it puts that array on the stack not on data memory or constant memory (rodata) if it determines its a constant. So if you get into the habit of using that form you can get some undesirable things happen.
Personally you are learning and I would learn to live without it and just learn them as you will most often see them written.