13

Possible Duplicate: Stack pointer difference for char pointer and array

To illustrate my question:

int main(void){
    int myary[20];
    int *myaryPtr;
    myaryPtr = myary;

    sizeof(myary); // Will it return 80? Correct?
    sizeof(myaryPtr); // Will it return 4? Correct?
    return 0;
}

First off, is my assumption correct?

And then assuming my assumption is correct, what is the detailed explanation? I understand that my 20 element array is 80 bytes, but isn't the name myary merely a pointer to the first element of the array? So shouldn't it also be 4?

Community
  • 1
  • 1
SystemFun
  • 1,062
  • 4
  • 11
  • 21
  • 1
    Subject to `sizeof(int) == 4` and `sizeof(int *) == 4`, the first of which is usually the case and the second is right for 32-bit systems (`sizeof(int *) == 8` on 64-bit systems), your assumptions about `sizeof` are correct. Arrays are not identical to pointers — witness the different result from `sizeof`. But this must be a duplicate of a number of other questions...the difficulty is finding them. – Jonathan Leffler Jan 12 '13 at 22:43
  • Sorry, I had difficult finding one that matched my exact question. – SystemFun Jan 12 '13 at 22:53
  • You might like to read section 6 of the [comp.lang.c FAQ](http://c-faq.com/). – pmg Jan 12 '13 at 22:58

2 Answers2

14

Yes, your assumption is correct, assuming an int and a pointer are both 4 bytes long on your machine.

And no, arrays aren't pointers. The array name sometimes decays into a pointer in certain contexts, but they aren't the same thing. There is a whole section of the comp.lang.c FAQ dedicated to this common point of confusion.

Carl Norum
  • 219,201
  • 40
  • 422
  • 469
  • simplest example is that array `char string[] = "test"` takes 5 bytes, while pointer to array `char *string = "test"` takes 5 bytes for string and `sizeof(char *)` for pointer itself. – aragaer Jan 12 '13 at 22:49
  • Ok, so an array is an object in the function it is local to, and then the array decays to a pointer when passed to other functions? – SystemFun Jan 12 '13 at 22:52
  • 1
    When is the array name *not* considered to be a pointer? – Theocharis K. Jan 12 '13 at 22:57
  • @Eric, yes, a function call is one place the array name decays to a pointer. The FAQ has a lot of details. – Carl Norum Jan 12 '13 at 22:57
  • 3
    @Aposperite, all the details you could possibly want are in the FAQ I linked in my answer. – Carl Norum Jan 12 '13 at 22:58
  • @Vlad: Yes, basically. More specifically, a function is not allowed to have a parameter of array type in C -- if you try to write one it will be interpreted as a pointer type instead. So, "array decays to a pointer when passed to other functions" *because* it sees that that function takes a pointer parameter. – newacct Jan 13 '13 at 00:34
  • 1
    @Aposperite: to name a few, the `&` operator on an array results in a pointer to an array. Also, `sizeof`. – newacct Jan 13 '13 at 00:36
3

The size of the array is not stored in memory in either case, whether you declare it as int myArr[20] or int* myArrPtr.

What happens is that sizeof() is replaced (by the compiler) with a constant value.

Therefore, because myArr was specified with a fixed size prior to compilation, the compiler knows just how big the amount of memory allocated is. With myArrPtr, you could dynamically allocate different array sizes, so only the size of the type is stored.

DiJuMx
  • 524
  • 5
  • 10
  • `sizeof` isn't always constant - it works for VLAs, for example. – Carl Norum Jan 12 '13 at 22:58
  • 1
    In that case the compiler could replace a `sizeof(int vla[n])` with an `n * sizeof(int)` where `sizeof(int)` would be a constant. Also section 6.15 of the above mentioned [FAQ](http://c-faq.com/) – DiJuMx Jan 12 '13 at 23:04
  • That's exactly what it does do. I was just commenting for clarity, since your answer says it's replaced with a constant, and that's not always the case. – Carl Norum Jan 12 '13 at 23:08
  • Very true. However, I haven't had experience with VLAs as the last time I tried to use them, I got compiler errors/warnings, so I've stuck with malloc/free – DiJuMx Jan 12 '13 at 23:09