Why can't I treat an array like a pointer in C?

Question

I see this question a lot on SO. Maybe not in so many words... but time and again there is confusion on how arrays are different from pointers. So I thought I would take a moment to Q&A a few points about this.

For purposes of this Q&A we're going to assume a 32-bit system and the following have been declared:

char * ptr = "hello";
char arr[10] = "hello";
int iarr[10] = {0};

Here's a list of questions that surmise the confusion I see on SO. As I see new ones I'll add to my list of Q&A (others feel free to as well, and correct me if you see any mistakes!)

1. Isn't a pointer and an array basically the same thing?
2. Follow up: both *(ptr) and *(arr), or ptr[0] and arr[0] give the same thing, why?
3. How come arr and &arr is the same value?
4. Follow up: why do I get a different value printing arr+1 vs &arr+1?

Escape

@Prætorian - That is absolutely a great link, the only reason why I was considering this to be separate was that is C++ specific. I was targeting this at C (hence the tag) and at the new programmers, I didn't want to confuse things with the templates and differences between C++ and C. – Escape

Comments on the downvotes please. I'm happy to clean things up but let's discuss what you don't like! Thanks. – Escape

You are missing half the picture. The only things you consider are statically declared arrays. There is another kind; dynamically declared arrays. These are the kinds of arrays that are declared with a variable expression as a size parameter, and also the kind that are passed into functions. Dynamically declared arrays also behave like pointers when using the & operator and the sizeof() function. It is also worth noting that when you pass a static array into a function, it is converted to a dynamic array, or in other words, the address is copied into a pointer. – Huebner

@Zistack: Dynamic arrays are a conceptual thing, and have no language aspect thought. Dynamic arrays are considered to be pointers at the language level. – Melanism

Answer 1

1) Pointers are not arrays. Arrays are not pointers. Don't think of them that way because they are different.
How can I prove this? Think about what they look like in memory:

Our array arr is 10 characters long. It contains "Hello", but wait, that's not all! Because we have a statically declared array longer than our message, we get a bunch of NULL characters ('\0') thrown in for free! Also, note how the name arr is conceptually attached to the contiguous characters, (it's not pointing to anything).

Next consider how our pointer would look in memory: Note here we're pointing to a character array some place in read only memory.

So while both arr and ptr were initialized the same way, the contents/location of each is actually different.

This is the key point:
ptr is a variable, we can point it to anything, arr is a constant, it will always refer to this block of 10 characters.

---

2) The [] is an "add and deference" operator that can be used on an address. Meaning that arr[0] is the same as saying *(arr+0). So yes doing this:

printf("%c %c", *(arr+1), *(ptr+1));

Would give you an output of "e e". It's not because arrays are pointers, it's because the name of an array arr and a pointer ptr both happen to give you an address.

Key point to #2: The deference operator * and the add and deference operator [] are not specific to pointers and arrays respectively. These operators simply work on addresses.

---

3) I don't have an extremely simple answer... so let's forget our character arrays for a second and take a look at it this example for an explanation:

int b;   //this is integer type
&b;      //this is the address of the int b, right?

int c[]; //this is the array of ints
&c;      //this would be the address of the array, right?

So that's pretty understandable how about this:

*c;   //that's the first element in the array

What does that line of code tell you? If I deference c, then I get an int. That means just plain c is an address. Since it's the start of the array it's the address of the array and also the address of the first element in the array, thus from a value standpoint:

c == &c;

---

4) Let me go off topic for a second here... this last question is part of the confusion of address arithmetic. I saw a question on SO at one point implying that addresses are just integer values... You need to understand that in C addresses have knowledge of type. That is to say:

iarr+1; //We added 1 to the address, so we moved 4 bytes
arr+1;  //we added 1 to the address, so we moved 1 byte

Basically the sizeof(int) is 4 and the sizeof(char) is 1. So "adding 1 to an array" is not as simple as it looks.

So now, back to the question, why is arr+1 different from &arr+1? The first one is adding 1 * sizeof(char)=1 to the address, the second one is adding 1 * sizeof(arr)=10 to the address.

This is why even though they are both "only adding 1" they give different results.

Escape

How does your answer to Q4 relate to Q4? – Ehrlich

"This is why ptr is considered an lvalue". No, that's not why ptr is considered to be an lvalue; after all arr is also considered to be an lvalue. – Mickey

@DavidHeffernan - I rewrote the Q&A4 a tiny bit. Does that help show how they relate? Just wanted to make it clear that +1 on an address isn't always the same (depending on what type the address is) – Escape

It's the Q that needs to be changed. Have a read of Q4 again. – Ehrlich

@CharlesBailey - Thanks for your input. arr is indeed a "named region of storage" (definition of an lvalue). But is it not considered a "unmodifiable lvalue" since the location where the first element will be stored can't be changed once arr is declared? Is my understanding incorrect, or is it the way I phrased things that you disagree with? – Escape

@Mike: I don't understand why you are evening mentioning lvalue. arr and ptr are both lvalues but so is every expression that is an identifier denoting a variable or reference. It just doesn't seem to be relevant to the pointer vs array discussion. – Mickey

@CharlesBailey Many people still believe that lvalue means can stand on the left of an assignment. – Brancusi

@FredOverflow: ...and perpetuating that understanding is not helpful. (IMHO) – Mickey

@CharlesBailey - Your point is taken, I removed the line in question as it doesn't really add value. Thanks! – Escape

As mentioned alredy, sizeof() gets a bit more tricky when arr is passed into a function. I think the array/pointer thing in C is one of those topics that only experience can turn them into some kind of "muscle memory". So practice, practice, practice :) Btw, in many cases it comes down to length vs size, and a safe rule of thumb is to always pass whichever you need along with the array in a function (or provide a safe alternative, like a sentinel value at the end of the array). – Derr