Newbie question about 'sizeof' and arrays

I'm a little confused about sizeof, pointers and arrays. I'm starting with the information that an array name is really just a pointer to the first element in the array. So far so good.

If I initialize an array like:

Code:

---

int mins[5] = {4, 6, 2, 7, 9};

---

then "sizeof mins" gives me 20 - the total size of the array. But how is this so? If 'mins' is really just a pointer to the first element of an array, then shouldn't it give me 4 (assuming a 4-byte address)?

Indeed, if I pass the pointer 'mins' to a function - e.g. 'sum(mins, 5)' - and that function header is:

Code:

---

int sum(int ar[], int n)

---

then if I ask for 'sizeof ar' I'm given 4, since 'ar' is a pointer. But isn't 'mins' also a pointer?

General sizeof/array/pointer confusion here! Help!

This is proper behavior. I suspect the reason for the difference is that the array size of mins is known at compile time. What happens if you specify

Code:

---

int sum(int ar[5], int n)

---

and take the sizeof ar?

Quote:

---

Originally Posted by Sharke

Code:

---

int mins[5] = {4, 6, 2, 7, 9};

---

then "sizeof mins" gives me 20 - the total size of the array. But how is this so?

---

mins is an array of 5 int´s so the sizeof mins is 4*5 = 20 bytes, since an int is 4 bytes.

So sizeof doesn't care about evaluating anything, it just cares about the type. mins is of type int[5] -- i.e., an array of five integers -- so it has size 20 (probably). However, when mins is evaluated by itself somewhere, it decays to an int* -- hence if it passed to a function, say, the function only knows that what was passed to it is an int*; the information about it actually being an array is gone.

Quote:

---

Originally Posted by drunken_scot

What happens if you specify

Code:

---

int sum(int ar[5], int n)

---

and take the sizeof ar?

---

I'm given the same value no matter what value I substitute for '5.'

Quote:

---

Originally Posted by tabstop

So sizeof doesn't care about evaluating anything, it just cares about the type. mins is of type int[5] -- i.e., an array of five integers -- so it has size 20 (probably).

---

This is what confuses me. I was under the impression that mins was of type "pointer to int" - i.e., a pointer to the first value of the array mins[], which is an int. I understand that the total size of the array in this case works out as 20 bytes, but not why sizeof mins gives that answer.

The confusion started because the book I'm working from just told me this a couple of pages ago:

Quote:

---

.....an array name is also the address of the first element of the array. That is, if 'flinzy' is an array, the following is true:

Code:

---

flinzy == &flinzy[0];

---

---

If 'flinzy' is an address, i.e. an int*, then shouldn't 'sizeof flinzy' return 4?

Quote:

---

Originally Posted by tabstop

However, when mins is evaluated by itself somewhere, it decays to an int* -- hence if it passed to a function, say, the function only knows that what was passed to it is an int*; the information about it actually being an array is gone.

---

I suppose I can hold this information in my head and accept it, but I still don't understand why sizeof mins gives the full size of the array, since mins is a pointer which holds an address. It just seems inconsistent with what I've held to be true so far.

Quote:

---

an array name is also the address of the first element of the array.

---

The book you got this information from is wrong. This is a very common misconception, though, and an understandable one. The thing is, almost all of the time, you can't tell the difference between an array and a pointer. You just happened to discover that sizeof is one of the few times that you can tell the difference. The only other time that really matters is with the & (address-of) operator. In other instances, you can treat an array name like a pointer, but you simply have to remember that it's not truly a pointer; it just gets converted to one in most cases.

As for the & operator:

Code:

---

void f(int **p)
{
}
int main(void)
{
  int *p, a[5];
  f(&p); /* OK */
  f(&a); /* Not OK!  Since a is not a pointer, &a is not a pointer-to-pointer */
  return 0;
}

---

It's just one of those C rules you have to remember.

The book I got it from was Prata's "C Primer Plus," 5th edition. Seems like a sloppy error for him to make! I guess I'll just plod on with this new knowledge feeling ever so slightly uneasy...though of course it'll probably click into place in time like everything else.

Thanks for all the replies.

Quote:

---

Originally Posted by Sharke

I suppose I can hold this information in my head and accept it, but I still don't understand why sizeof mins gives the full size of the array, since mins is a pointer which holds an address...

---

Frankly I too haven't been able to find a satisfactory answer. The "sizeof operator" section given in Appendix A of K&R's ANSI C book says that:

"when applied to an array, the result is the total number of bytes in the array ..."

Don't know if that helps or not?

Quote:

---

Originally Posted by itCbitC

Frankly I too haven't been able to find a satisfactory answer.

---

Then read tabstop's post #4 and cas' post #6.

Quote:

---

Originally Posted by laserlight

Then read tabstop's post #4 and cas' post #6.

---

What I have come across in different books, manuals etc. is that is if the array is:

Code:

---

int mins[5];  /* the type of mins is "pointer to ..." */

---

Quote:

---

Originally Posted by itCbitC

What I have come across in different books, manuals etc. is that is if the array is:

Code:

---

int mins[5];  /* the type of mins is "pointer to ..." */

---

---

Then those "different books, manuals etc" are wrong. From the 1999 edition of the C standard, section 6.3.2.1 paragraph 3:

Quote:

---

Except when it is the operand of the sizeof operator or the unary & operator, or is a string literal used to initialize an array, an expression that has type ‘‘array of type’’ is converted to an expression with type ‘‘pointer to type’’ that points to the initial element of the array object and is not an lvalue.

---

Section 6.7.5.2 on "array declarators" more directly contradicts the material that you have read, but I think it is harder to make sense of for those less familiar with "standardese".

Isn't that exactly what I said in my posts, since those statements were extracted from the Appendix given in the back of K&R's ANSI C.

Quote:

---

Originally Posted by itCbitC

Isn't that exactly what I said in my posts, since those statements were extracted from the Appendix given in the back of K&R's ANSI C.

---

It is not. The additional part concerns the fact that array types exist, and not just pointer types. If you already know this, then what are you not satisfied about?

Cool beans! that's what I said in post #8 that the name of the array mins is of the type pointer to ... but its size is the total number of bytes in it. I accept what the Gods (K&R) have created but was looking for justification behind that rule.

Quote:

---

Originally Posted by itCbitC

Cool beans!

---

:cool:

Quote:

---

Originally Posted by itCbitC

that's what I said in post #8 that the name of the array mins is of the type pointer to

---

But that is wrong: an array is an array, not a pointer. Under most circumstances, an array is converted to a pointer to its first element, but its type remains "array of type", not "pointer to type". This is what tabstop and cas have stated earlier in this thread.

Consequently, the sizeof rule makes sense: you are asking for the size of an array, not the size of a pointer.

I do believe an array name IS the first value's address.

For example:

Code:

---

int array[5];
*(array) = 5;
array[0] = 5; // same thing

---

So in a way, an array is a pointer, but they have distinctions of course.

Quote:

---

Originally Posted by execute

I do believe an array name IS the first value's address.

---

As I have repeated, no, that is not true. Semantically, a conversion happens from array to pointer to first element of array.

Quote:

---

Originally Posted by execute

So in a way, an array is a pointer, but they have distinctions of course.

---

Yes, you could look at it like that, especially since array notation and pointer notation are also mostly interchangeable.

Quote:

---

Originally Posted by laserlight

Except when it is the operand of the sizeof operator or the unary & operator, or is a string literal used to initialize an array, an expression that has type ‘‘array of type’’ is converted to an expression with type ‘‘pointer to type’’ that points to the initial element of the array object and is not an lvalue.

---

Isn't it the same thing then?
If int mins[5] then mins is of the type pointer to int (a[0] specifically), but its size is the total no. of bytes that make up that object ie if int is 4 bytes then 5*4 = 20 bytes. I fail to see the difference in what you have quoted and what is given in K&R's ANSI C book.

Quote:

---

Originally Posted by itCbitC

Isn't it the same thing then?
If int mins[5] then mins is of the type pointer to int (a[0] specifically), but its size is the total no. of bytes that make up that object ie if int is 4 bytes then 5*4 = 20 bytes. I fail to see the difference in what you have quoted and what is given in K&R's ANSI C book.

---

I would suggest reading what you quote. An expression that has type "array of foo" has type "array of foo" more or less by definition. It can be converted to an expression of "pointer to foo", but it is not, in and of itself, of that type.

I don't have a copy of K&R, so I don't actually know what you're referring to. Do you mean

Code:

---

int mins[5];  /*the type of mins is pointer to int*/

---

? If so, then I'm a little bit surprised (ok, a lot surprised) that that appears. I understood that arrays were a bolted-on after-market accessory to original C, but I thought that by the time ANSI came around arrays were a full part of the language.

Quote:

---

Originally Posted by itCbitC

Isn't it the same thing then?
If int mins[5] then mins is of the type pointer to int (a[0] specifically), but its size is the total no. of bytes that make up that object ie if int is 4 bytes then 5*4 = 20 bytes.

---

I can admit that this is being pedantic, but there is a pedantic difference. If you say that mins is of type pointer to int, then it follows that sizeof(mins) == sizeof(int*), and likewise sizeof(mins) == sizeof(&mins[0]). However, empirically you know that this is not the case. The explanation is that mins is not a pointer; it is an array.

Let's use cas' other example. Now, you say that mins is of type pointer to int. That implies that &mins is of type pointer to pointer to int. So, we can write this program:

Code:

---

#include <stdio.h>

int main(void)
{
    int mins[5] = {0, 1, 2, 3, 4, 5};
    int **p = &mins;
    printf("%d\n", (*p)[1]);
    return 0;
}

---

Since p of type int**, *p is of type int*, and (*p)[1] is of type int. We expect that the output is 1. Compile and run the program. What output do you get?

Quote:

---

Originally Posted by tabstop

I would suggest reading what you quote. An expression that has type "array of foo" has type "array of foo" more or less by definition. It can be converted to an expression of "pointer to foo", but it is not, in and of itself, of that type.

---

I guess all I am trying to say is that the compiler has double-standards (no pun intended!) when it comes to arrays. When given as the operand to the sizeof operator, it's an object that has been allocated a chunk of bytes; otherwise it's converted to be of the type "pointer to ..." though it's not an lvalue as it's a const*.

Quote:

---

Originally Posted by tabstop

I don't have a copy of K&R, so I don't actually know what you're referring to. Do you mean

---

excerpt from book below and perhaps you can clear the mists swirlin' in head!

Code:

---

primary-expression [ expression ]
A primary expression followed by an expression in square brackets is a primary expression.
The intuitive meaning is that of a subscript. Usually, the primary expression has type ‘‘pointer
to . . .’’, the subscript expression is int, and the type of the result is ‘‘ . . . ’’. The expression ‘‘E1
[E2]’’ is identical (by definition) to ‘‘* ( (E1) + ( E2 ) ) ’’. All the clues needed to understand this
notation are contained in this section together with the discussions in ...

---

Quote:

---

Originally Posted by tabstop

? If so, then I'm a little bit surprised (ok, a lot surprised) that that appears. I understood that arrays were a bolted-on after-market accessory to original C, but I thought that by the time ANSI came around arrays were a full part of the language.

---

AFAIK arrays were in pre ANSI C too though frankly I'm not sure if they were bolted on as a value added selling point.

Quote:

---

Originally Posted by itCbitC

I guess all I am trying to say is that the compiler has double-standards (no pun intended!) when it comes to arrays. When given as the operand to the sizeof operator, it's an object that has been allocated a chunk of bytes; otherwise it's converted to be of the type "pointer to ..." though it's not an lvalue as it's a const*.

---

I agree, but I suppose that the practical reason is that copying the array would have been an expensive default, leading to a proliferation of &a[0] to pass an array named a as an argument. Making the conversion to a pointer to the first element as a default simplifies that syntax, at the cost of introducing special cases somewhere else.

Quote:

---

Originally Posted by itCbitC

excerpt from book below and perhaps you can clear the mists swirlin' in head!

---

execute's comment in post #16 seems fine to me: "so in a way, an array is a pointer, but they have distinctions of course".

Quote:

---

Originally Posted by itCbitC

I guess all I am trying to say is that the compiler has double-standards (no pun intended!) when it comes to arrays. When given as the operand to the sizeof operator, it's an object that has been allocated a chunk of bytes; otherwise it's converted to be of the type "pointer to ..." though it's not an lvalue as it's a const*.

excerpt from book below and perhaps you can clear the mists swirlin' in head!

Code:

---

primary-expression [ expression ]
A primary expression followed by an expression in square brackets is a primary expression.
The intuitive meaning is that of a subscript. Usually, the primary expression has type ‘‘pointer
to . . .’’, the subscript expression is int, and the type of the result is ‘‘ . . . ’’. The expression ‘‘E1
[E2]’’ is identical (by definition) to ‘‘* ( (E1) + ( E2 ) ) ’’. All the clues needed to understand this
notation are contained in this section together with the discussions in ...

---

AFAIK arrays were in pre ANSI C too though frankly I'm not sure if they were bolted on as a value added selling point.

---

So here's where the word "conversion" comes in again. If E1 is an array, and the name is evaluated by itself, it is converted to a pointer to the first element (not permanently; think of it as a new temporary object of type pointer to ... if you want). So E1[E2] is syntactic sugar for *(E1 + E2); in this expression E1 is evaluated by itself (before the +E2 happens), so the conversion happens. (And then the pointer arithmetic happens, and the dereferencing.)

From reading the to and fro here today I think the concept has settled in my head somewhat. The array name is not really a pointer, it's just converted to/used as one in certain situations, like when passing an array as an argument into a function. But since it's not really a pointer, the operator sizeof gives the total size of the array as expected. Am I right? I'm pretty much new to C and the concept of pointers and as I was warned, it can be a little tricky to the beginner!

Quote:

---

Originally Posted by Sharke

From reading the to and fro here today I think the concept has settled in my head somewhat. The array name is not really a pointer, it's just converted to/used as one in certain situations, like when passing an array as an argument into a function. But since it's not really a pointer, the operator sizeof gives the total size of the array as expected. Am I right? I'm pretty much new to C and the concept of pointers and as I was warned, it can be a little tricky to the beginner!

---

Yep, that's pretty much it!

Quote:

---

Originally Posted by Sharke

From reading the to and fro here today I think the concept has settled in my head somewhat. The array name is not really a pointer, it's just converted to/used as one in certain situations, like when passing an array as an argument into a function.

---

Yes, that's true.

Quote:

---

But since it's not really a pointer, the operator sizeof gives the total size of the array as expected. Am I right? I'm pretty much new to C and the concept of pointers and as I was warned, it can be a little tricky to the beginner!

---

Well, the thing is that sizeof (once again) does not decay the array into a pointer, thus sizeof sees the "real type" and can deduce the size from that.
But when you use the array somewhere else, such as pass it into a function, it becomes a real pointer, and thus sizeof sees the type of the pointer.

It worked on the function you declared the argument as an ar[5], it didn't work on the function where the parameter was declared as a[] because a[] = *a.

That's not right. It doesn't matter if you put the actual size in the function header.
The compiler ignores it. What is passed is a pointer, plain and simple, thus sizeof returns the size of T*, not T[n].