Initializing Pointer to an array

[rupesh_533]

I am assuming the following things.
1.Pointer to an integer means it points to an integer,On incrementing
the pointer,it points to the next integer in memory.
2.Pointer to an array of some size means it points to an array,On
incrementing the pointer,it should point to next array of that size.

Correct me if i am wrong.
We declare a pointer to an integer array of Size N as
int (*a)[N];

Now My Problem is
I have an array of 100 Integers,Pointer to an array of 10 integers
int (*a)[10];
int b[100];
How can i initialize the pointer a to point to the array b base
address.

 

[rupesh_533]

I am able to initialize the pointer to the array as
int (*a)[10];
int b[100];

a = &b[0];
But i am getting the warning
warning: assignment from incompatible pointer type

My Code is
int main()
{
int (*a)[10];
int b[100];
int i;

for(i=0;i<100;i++)
b=i;

a = &b[0];

printf(" %u %u %d %d\n",a ,&b[0],**a,b[0]);
a++;
printf(" %u %u %d %d\n",a ,&b[10],**a,b[10]);
a++;
printf(" %u %u %d %d\n",a , &b[20],**a,b[20]);
a++;
printf(" %u %u %d %d\n",a , &b[30],**a,b[30]);
}

I am getting correct results as
3221219184 3221219184 0 0
3221219224 3221219224 10 10
3221219264 3221219264 20 20
3221219304 3221219304 30 30

 

[Christopher Benson-Manica]

I am able to initialize the pointer to the array as
int (*a)[10];
int b[100];

a = &b[0];
But i am getting the warning
warning: assignment from incompatible pointer type

Of course you are. a is a pointer to an array of 10 ints (which
you probably do not need), while &b[0] is a pointer to an int. Your
compiler is doing you a favor.

My Code is
int main()

int main( void ) /* better */

{
int (*a)[10];
int b[100];
int i;

for(i=0;i<100;i++)

for( i=0; i < sizeof b; i++) /* better */

b=i;

a = &b[0];

Wrong, as I said.

printf(" %u %u %d %d\n",a ,&b[0],**a,b[0]);

Wrong in multiple ways:

1) You did not include <stdio.h>.
2) %u is not the conversion specifier you want for pointers.

printf( " %p %p %d %d\n", (void*)a, (void*)&b[0], **a, b[0] );

Note the casts; they are required.

a++;
printf(" %u %u %d %d\n",a ,&b[10],**a,b[10]);
a++;
printf(" %u %u %d %d\n",a , &b[20],**a,b[20]);
a++;
printf(" %u %u %d %d\n",a , &b[30],**a,b[30]);

Unless you are using a C99 compiler, you must return a value from
main(). Your compiler should have warned you about this unfortunate
omission.

 

[Antonio Contreras]

Christopher Benson-Manica wrote:

int main()

int main( void ) /* better */

{
int (*a)[10];
int b[100];
int i;

for(i=0;i<100;i++)

for( i=0; i < sizeof b; i++) /* better */

Shouldn't that be:
for (i = 0; i < ((sizeof b) / (sizeof int)); i++)
??

 

[Christopher Benson-Manica]

for (i = 0; i < ((sizeof b) / (sizeof int)); i++)

Yes. Ouch. (And thank you.)

 

[Flash Gordon]

Yes. Ouch. (And thank you.)

Or better yet:
for (i = 0; i < ((sizeof b) / (sizeof *b)); i++)

Then it will compile (apart from being incomplete and the certainty of
me introducing an error in my correction) and be independant of the type
of array b.

 

[Antonio Contreras]

Or better yet:
for (i = 0; i < ((sizeof b) / (sizeof *b)); i++)

Then it will compile (apart from being incomplete and the certainty of
me introducing an error in my correction) and be independant of the type
of array b.

Well, for purely aesthetic reasons I would prefer the totally
equivalent:

for (i = 0; i < ((sizeof b) / (sizeof b[0])); i++)

Call me paranoid, but the equivalence between arrays and pointers is
confusing enough [1] without dereferencing pointers that have been
created by the decay of an array name.

[1] Actually I've gotten used to it and it's not confusing anymore, but
it was really confusing two years ago.

 

[Michael Wojcik]

int (*a)[10];
int b[100];
int i;

for(i=0;i<100;i++)

for( i=0; i < sizeof b; i++) /* better */

Shouldn't that be:
for (i = 0; i < ((sizeof b) / (sizeof int)); i++)

When the sizeof operator is applied to a type, the name of the type
must be parenthesized. You're missing parentheses around "int"
(which is ironic, considering all the unnecessary sets of parentheses
you have there).

What would be better is

for (i = 0; i < sizeof b / sizeof *b; i++)

which works for a "b" of any (complete) array type.

 

[Peter Nilsson]

Unless you are using a C99 compiler, you must return a value from
main().

It's not mandatory un C90, just desirable.

Your compiler should have warned you about this unfortunate
omission.

Perhaps, but unlike C++, both C90 and C99 allow non-void functions to
fail
to return a value. So long as the calling function doesn't attempt to
use
the value, all is fine.

As this is a <cough> feature of the language, many old compilers won't
issue a warning for this.

 

[Jack Klein]

Or better yet:
for (i = 0; i < ((sizeof b) / (sizeof *b)); i++)

Then it will compile (apart from being incomplete and the certainty of
me introducing an error in my correction) and be independant of the type
of array b.

Well, for purely aesthetic reasons I would prefer the totally
equivalent:

for (i = 0; i < ((sizeof b) / (sizeof b[0])); i++)

Call me paranoid, but the equivalence between arrays and pointers is
confusing enough [1] without dereferencing pointers that have been
created by the decay of an array name.

The sizeof operator never evaluates the value of its operand in C
prior to C99, and only to determine the size of a variable length
array in C99. Under no circumstances does sizeof dereference a
pointer given to it as an argument.

Plus the C language absolutely requires that the expression b[0] be
evaluated as if written *b, so the Christopher's code and your
alternative are exactly equivalent in C.

[1] Actually I've gotten used to it and it's not confusing anymore, but
it was really confusing two years ago.

In either case, there is no evaluation of the value of b[0] or *b, and
no dereference.

 

[Christopher Benson-Manica]

It's not mandatory un C90, just desirable.

I suppose that's strictly correct, but it's probably safe to assume
that a reasonable host environment will attempt to use the termination
status of main. I would think that the chances of UB on a hosted
implentation would be rather high.

 

[Zara]

I suppose that's strictly correct, but it's probably safe to assume
that a reasonable host environment will attempt to use the termination
status of main. I would think that the chances of UB on a hosted
implentation would be rather high.

C *and* C++ specify that reaching the the terminating } of main() will
return 0; so this function *always* return a valid value.

 

[Christopher Benson-Manica]

C *and* C++ specify that reaching the the terminating } of main() will
return 0; so this function *always* return a valid value.

C89 does not.

 

[Flash Gordon]

C89 does not.

And, just to emphasise the point, there are far more people using
implementations that can support C89 correctly (modulo bugs) than there
are people using conforming C99 implementations. For a start, neither
gcc nor MS VC++ fully support C99 but both fully support C89 (modulo bugs).

 

[Tim Rentsch]

Plus the C language absolutely requires that the expression b[0] be
evaluated as if written *b,

Usually but not always.

void
foo(){
int a[10];
int (*b)[] = &a;
int *c;

c = b[0]; /* this doesn't work */
c = *b; /* this works */
}

Personally, I'd be in favor of adding a rule that makes the two
forms equivalent in the case of a 0-valued constant expression.
But that's another story.

 

[Antonio Contreras]

Christopher Benson-Manica wrote:

for (i = 0; i < ((sizeof b) / (sizeof int)); i++)

Yes. Ouch. (And thank you.)

Or better yet:
for (i = 0; i < ((sizeof b) / (sizeof *b)); i++)

Then it will compile (apart from being incomplete and the certainty of
me introducing an error in my correction) and be independant of the type
of array b.

Well, for purely aesthetic reasons I would prefer the totally
equivalent:

for (i = 0; i < ((sizeof b) / (sizeof b[0])); i++)

Call me paranoid, but the equivalence between arrays and pointers is
confusing enough [1] without dereferencing pointers that have been
created by the decay of an array name.

The sizeof operator never evaluates the value of its operand in C
prior to C99, and only to determine the size of a variable length
array in C99. Under no circumstances does sizeof dereference a
pointer given to it as an argument.

I didn't imply that. What I tried to say is that it "looks" like it,
and that it is confusing when you're learning C. IMHO, given that b is
an array, b[0] is less confusing than *b.

Plus the C language absolutely requires that the expression b[0] be
evaluated as if written *b, so the Christopher's code and your
alternative are exactly equivalent in C.

I acknowledge that much. I literally said "I prefer the _totally
equivalent_..."

[1] Actually I've gotten used to it and it's not confusing anymore, but
it was really confusing two years ago.

In either case, there is no evaluation of the value of b[0] or *b, and
no dereference.

Again, I didn't try to imply that. I guess it was a really bad wording
from my side.

 

[Barry Schwarz]

Plus the C language absolutely requires that the expression b[0] be
evaluated as if written *b,

Usually but not always.

void
foo(){
int a[10];
int (*b)[] = &a;
int *c;

c = b[0]; /* this doesn't work */
c = *b; /* this works */

Are you sure? n1124 states in 6.5.2.1(2) that

A postfix expression followed by an expression in square brackets []
is a subscripted designation of an element of an array object. The
definition of the subscript operator [] is that E1[E2] is identical to
(*((E1)+(E2))). Because of the conversion rules that apply to the
binary + operator, if E1 is an array object (equivalently, a pointer
to the initial element of an array object) and E2 is an integer,
E1[E2] designates the E2-th element of E1 (counting from zero).

So b[0] is the same as *(b+0) which is the same as *b. Both
expressions should evaluate to the address of a with type array of 10
int which, since it is not one of the exceptions, will then be
converted to the address of a[0] with type pointer to int.

}

Personally, I'd be in favor of adding a rule that makes the two
forms equivalent in the case of a 0-valued constant expression.
But that's another story.

<<Remove the del for email>>

 

[S.Tobias]

Plus the C language absolutely requires that the expression b[0] be
evaluated as if written *b,

Usually but not always.

void
foo(){
int a[10];
int (*b)[] = &a;
int *c;

c = b[0]; /* this doesn't work */
c = *b; /* this works */

Are you sure? n1124 states in 6.5.2.1(2) that

A postfix expression followed by an expression in square brackets []
is a subscripted designation of an element of an array object. The
definition of the subscript operator [] is that E1[E2] is identical to
(*((E1)+(E2))). Because of the conversion rules that apply to the
binary + operator, if E1 is an array object (equivalently, a pointer
to the initial element of an array object) and E2 is an integer,
E1[E2] designates the E2-th element of E1 (counting from zero).

So b[0] is the same as *(b+0) which is the same as *b.

They are not the same. `b+0' has an additional constraint:
6.5.6#2
# [#2] For addition, either both operands shall have
# arithmetic type, or one operand shall be a pointer to an
# object type and the other shall have integer type.

("Object type" is a complete type.)

Both
expressions should evaluate to the address of a with type array of 10
int which,

`*b' is an incomplete (array) type lvalue.

since it is not one of the exceptions, will then be
converted to the address of a[0] with type pointer to int.

Yes.

 

[Flash Gordon]

Plus the C language absolutely requires that the expression b[0] be
evaluated as if written *b,

Usually but not always.

void
foo(){
int a[10];
int (*b)[] = &a;
int *c;

c = b[0]; /* this doesn't work */
c = *b; /* this works */

Are you sure? n1124 states in 6.5.2.1(2) that

A postfix expression followed by an expression in square brackets []
is a subscripted designation of an element of an array object. The
definition of the subscript operator [] is that E1[E2] is identical to
(*((E1)+(E2))). Because of the conversion rules that apply to the
binary + operator, if E1 is an array object (equivalently, a pointer
to the initial element of an array object) and E2 is an integer,
E1[E2] designates the E2-th element of E1 (counting from zero).

So b[0] is the same as *(b+0) which is the same as *b.

They are not the same. `b+0' has an additional constraint:
6.5.6#2
# [#2] For addition, either both operands shall have
# arithmetic type, or one operand shall be a pointer to an
# object type and the other shall have integer type.

("Object type" is a complete type.)
Yes.

Both
expressions should evaluate to the address of a with type array of 10
int which,

`*b' is an incomplete (array) type lvalue.

*b being an incomplete type is irrelevant since it is *(b+0) NOT *b +0
so 0 is added to b not to *b.

since it is not one of the exceptions, will then be
converted to the address of a[0] with type pointer to int.

Yes.

 

[S.Tobias]

On 21 Oct 2005 12:22:00 -0700, Tim Rentsch <[email protected]>
wrote:
void
foo(){
int a[10];
int (*b)[] = &a;
int *c;

c = b[0]; /* this doesn't work */
c = *b; /* this works */

[snip]

So b[0] is the same as *(b+0) which is the same as *b. ....
Both
expressions should evaluate to the address of a with type array of 10
int which,

`*b' is an incomplete (array) type lvalue.

*b being an incomplete type is irrelevant since it is *(b+0) NOT *b +0
so 0 is added to b not to *b.

Right. I did mean `*b', but I misunderstood what Barry had said, so my
answer was irrelevant, too.

One more try: `*b' evaluates to an incomplete array type lvalue
for the array `a', which is immediately converted to the pointer to
the first element of `a' (not: "to the address of `a'"; unless "address"
is understood as "location").